Laravel 4 Thoughts/Questions/Etc.

laravel4.md

Laravel 4 Thoughts/Questions/Etc.

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 through artisan 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.

Another idea for composer dump-autoload for those not using command line to make controllers is to maybe have an option enabled for a developer mode that would run that command if a controller is requested and doesn't exist.

I'll address a few of these :)

• I do believe Route::resource should create named routes and plan to add that before final release.
• I have searched for a decent Pluralizer on packagist, but it seems there is not one available. If I can't find one I will probably port the L3 pluralizer into a composer package and use that for pluralizing models.
• Some HTML / Form helpers will be brought back into L4 before release, but possibly not all. I personally don't like being in the business of maintaining mark-up helpers as people can get pretty opinionated about them and they end up using a lot of pull requests which I think could be used for more important issues.

Also, yes, it will be very easy for me to make controller:make dump the composer autoload mappings. Of course, you are free to set your application up using psr-0 so you don't have to dump mappings at all.

Thanks, Taylor. This helps a lot! I want to make a reference guide for people upgrading -- just so they know some of the gotchas to look out for.

Yeah, I should also add that generating URLs to resourcefull controllers could be done also via: URL::action('UserController@show')

The database seeds also seem a bit strange to me. How do naming conventions work?
What if i have foreign keys and want to insert data in the correct order etc

I was thinking just making them part of migrations would be easier, keeps things bundled together nicely

@taylor - Yeah...not as elegant though, imo.

@wayne - You just name the seed file the same as the table, I believe. Works fine for me.

@wayne - You can seed as part of migrate:refresh. So: php artisan migrate:refresh --seed

Which helpers are missing that you use often? I know most of the most used ones are in. Maybe Taylor just forgot about them, because I know he forget ends_with() earlier on.

I actually shamelessly ported Laravel 3's HTML class. You might want to check it out. https://github.com/meido/html

@jasonlewis The Form helper wasn't there last time I checked.

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:

php artisan migrate:make create_tasks_table --table=tasks --create

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 TASKS

It would be much cleaner (and learnable) if folks only needed to do:

php artisan migrate:make create_users_table

...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.

@JeffreyWay I very much second that. Couldn't your script be used in L4 as a task as in L3?

@dex - Not sure. That script was never meant to be a permanent thing. It's actually a messy bit of code, that was only ever intended to be a temporary solution.

$this->layout is not longer available in controllers - I really liked this for loading templates because I could just specify the default template in a BaseController and then override in specific controllers or functions as needed. It may be possible to replicate this in L4 by overriding protected function processResponse() in controller.php. Are there any other alternatives?

I also can't see anything to deal with uri segments

Creating nested controllers with artisan doesn't seem to work

php artisan controller:make blog/PostsController

// folder must exit
// filename is correct
// class name is incorrect: 
class blog/PostsController extends Controller {
...
}

// should be 
class PostsController extends Controller {
...
}

Its created in the correct folder, but the controller name comes out :

When doing reverse routing, you now have to specify the key's name for replacement

// L3
HTML::link_to_action('posts@edit', 'Edit', array($post->id)); 

// L4
HTML::linkAction('PostsController@Edit', 'Edit', array('id' => $post->id)); 

Nested controllers comment above did not come out right

// should be 
class Blog_PostsController extends Controller {
...
}

$this->layout is available for controllers in the latest updates to the app repository (yesterday). Also available is wildcard (CodeIgniter) style routing (also available in L3): Route::controller('UserController', 'users');

Also, when creating nested controllers, use the --path option available on the command (relative to the project root). Although I should note that nested controllers may not be as necessary as controller routing is totally de-coupled from file system structure. Although, you are free to use them for organizational purposes.

Not sure if the following is common knowledge or not. Tripped me up a little, though.

Determining whether a named route is the current route has changed. Not sure if the new way worked in L3, too. But, it's nice and short.

Request::route()->is('home'); // L3 from the docs
Route::is('home'); // L4

Noticed some Blade syntax changes:

@layout('master') // L3
@extends('master') // L4

@endsection // L3
@stop // L4

To add support to Html/Scripts/Forms add this to your composer.json

"meido/html": ">=1.0.0",
 "meido/form": ">=1.0.0"

and this to your app.php

'Meido\HTML\Providers\HTMLServiceProvider',
'Meido\Form\Providers\FormServiceProvider',

is there a general consensus regarding using nested resources? IE: Route::resource('posts.comments.votes')

Form::open(array('route' => 'posts.comments.votes'))
HTML::link_to_route('posts.comments.votes')
URL::to_route('posts.comments.votes')

If not maybe something like explode on ' . ' and set keys

array( 'post' => 'id', 'comment''=> 'id', 'vote' => 'id' )

or even better, have it read from the url somehow.