This is just a random list of notes, as I dig into Laravel 4. If you have any feedback/solutions, please leave a comment. I'll be compiling everything for an article on Nettuts+, when the framework is officially in Beta. This will be updated over the course of the week.
-
Running
composer dump-autoload
after every new controller is a pain. Can this not be automated throughartisan controller:make ControllerName
? -
Seems that some of the View HTML helpers are missing. No
HTML::script()
. -
Route::resource('tasks', 'TasksController')
doesn't seem to create named routes. This is a big deal, if not. What's the solution? -
If you come from the Rails-flavor of REST, it'll take some re-tooling to learn the new RESTful method names. PHP can't use names, like "new," so that can be confusing. "create" is used instead.
-
Routing wildcards are different in L4. Rather than
(:num)
or(:any)
, you can name them.Route::get('tasks/{id}');
. Much better. -
A lot of the helpers are missing. I guess I see why that was done, but I'll likely end up implementing the most used ones on my own (
dd()
, etc.) -
Why does Laravel 4 now require me to specify the table name in my models? Why not use a natural default so that I can type less - such as the plural form of the class name?
-
return Task::all()
will now return a JSON representation, which is super helpful. It makes building RESTful APIs along with something like Backbone as easy as possible. -
artisan key:generate
doesn't seem to be currently available.
I haven't put a huge amount of thought into this, but I still think that the process of creating a new migration is too cumbersome. For example, to add a new tasks table to my db, I'd do:
Why not instead advocate a naming convention for migrations, and remove the need to be so redundant? The name of the migration specifies everything we need:
create_tasks_table
= CREATE a table, called TASKSIt would be much cleaner (and learnable) if folks only needed to do:
...and Laravel would be smart enough to parse the migration name, and proceed accordingly. Or, if no flags are passed, Laravel tasks a best-guess approach, but the developer is still free to be explicit.