Packt Publishing recently got in touch, asking me to review their new book, Learning Laravel 4 Application Development by Hardik Dangar. The timing was nice as I'm currently developing my first application on Laravel 4 (having had some light experience with Laravel 3), and more resources for documentation are never a bad thing.

I wasn't interested in the first few chapters (covering the MVC pattern and installation of Laravel) and jumped right into the chapter explaining the L4 file structure on page 20. The explanations of what's what are quite good, as is the diagram explaining the typical request flow, but things start getting murky in the "Configuring Laravel" section; it doesn't flow or seem to follow any logical structure, but rather jumps around quite suddenly.

For example, the author explains that "Laravel manages different types of configurations in different types of files," and then proceeds to list three of these (important, but otherwise seemingly arbitrary) files, without any mention of the others (or even that there are others), and then, quite out of the blue, shows PHP code from one of the files that wasn't even mentioned. For a few minutes I thought I was missing a page...

That PHP code is then followed by:

"The preceding configuration is used by Laravel when we generate a new package via the artisan workbench command. We can get this configuration value anywhere in our project via option. An example of this is as follows:

$option = Config::get('workbench.name');"

The configuration value is accessed via the get() method in the Config class. It is not accessed "via option," but rather assigned to a variable of that name. This wording is misleading and could be very confusing to anyone that's new to programming. The next paragraph (which attempts to explain that you can create custom configuration files) is even more confusing.

Moving further, the examples are sparse, omit important pieces of information, and make rather unreasonable assumptions about the reader.

Sure enough, one of the very first artisan (command-line interface to Laravel) commands is incorrect, too. Under Generating a boilerplate controller, the command is provided as php artisan controller make:user, whereas the correct command would be php artisan controller::make user. A small mistake, but one that leaves a poor impression.

Writing books is hard, and errata is inevitable, but these issues, along with the rather "rough around the edges" writing, are unfortunately enough for me to immediately put this book down and revert back to the official documentation. So many issues in such a short span do not reflect well on the book (especially if extrapolated).