Tag Archives: Laravel

Updating related models in Laravel

Not sure how other frameworks handle this (if they do), but Laravel’s ability to simply update a related model is pretty nice.

 $video->videoevent()->update(array('event_date' => createDbDate(Input::get('event_date'))));

Assuming I have a relationship between Video and Videoevent have made ‘event_date’ available for mass assignment the Videoevent model, magic happens.

The scary thing about relying on Composer with Laravel 4

This kind of sums up my concerns about over-reliance on Composer for what some people might consider core functionality in a PHP Framework.

Over 3000 installs on Packagist, and now suddenly, this package for Laravel to replace functionality left out (for now) from Laravel 4 is not being maintained anymore.

An explanation, but not very comforting: http://forums.laravel.io/viewtopic.php?id=6050

Random thoughts about Web Development across multiple dev machines

I just picked up a refurbished 2012 Macbook Air from the Apple online store to replace a 2007 Macbook Pro. I didn’t use the MBP much because it just couldn’t keep up, but I missed being able to work anywhere, including at home without having to sneak upstairs to the office.

Now that I have the MBA, those limitations are gone, but  working on the same project on different computers can still be a challenge. However, compared to just a few years ago, creating the same web development environment across several computers can be accomplished with just a little effort.

Continue reading

A few little concerns about Laravel 4

I jumped into Laravel as my PHP Framework of choice about a month ago after deciding to switch full time to PHP from Coldfusion. Though I’ve only used it for a month, I really believe Laravel 3 is an awesome framework. However, now that the beta 1 of Laravel 4 has come out, and I’ve been looking into what it would take to port my first Laravel 3 app to 4, I do have a few concerns and I’m not the only one.

I’m not so concerned about the controller/action naming conventions or the use of Composer in general, but the practical day-to-day stuff that will affect me as I’m developing.

One of the first things I noticed in my attempt to port over my app was the absence of the HTML, FORM, and URI (I think) helper functions. This was explained to be a result of using replacement packages available via Composer. That’s fine, but here’s my biggest concern regarding a heavy reliance on Composer (and this is not restricted to Laravel at all):

As a newbie I rely HEAVILY on documentation. The more you strip out of the framework and farm out to Composer, the more places I have to go to find documentation. This can be a pain.

Now I’m seeing there’s a movement afoot to buy a license for Redactor.js so it can be included in Laravel 4. That sounds great to me, but why would Laravel’s developers want to include a wysiwyg editor as part of the core, when they’re stripping out stuff like HTML and FORM helpers?
I can see not including a Twitter library like Zend, buy why remove something that was already there and relied upon by many developers?
I’m just ranting here, and I’m very hopeful that as things stabilize and the smoke clears, L4 will be awesome and even better than L3 has been for me so far.

But I’m still just a little concerned.

My Introduction to the Laravel PHP framework

Disclaimer: I don’t claim to be a framework expert. In fact, I’ve only used 3 to any real degree – Codeigniter(PHP), CFWheels(CF), and now Laravel(PHP). Actually, to be even more precise, I’m not an expert at anything.

I’ve written a lot of bad code. All developers have. It still bugs me when I look at some of the old stuff. For some developers like myself, MVC frameworks are there to help us from writing really, really bad code. Even for very small web apps, I find myself benefiting from the structure provided by a framework. So choosing a new framework, especially when you are jumping in to a different programming language (PHP), is kind of a big deal.

Laravel - A Clean & Classy PHP Framework

I’ve dabbled in PHP a little over the years, and have used Codeigniter for a couple of small projects. So when I decided to move to PHP, Codeigniter seemed like the logical candidate for a framework: I’d used it before, it’s well-supported, well-documented, and has a large community. But I kept hearing about another framework called Laravel (version as of this writing: 3.2.12). It also appeared to be well-supported and well-documented, and the size of the community, though dwarfed by Codeigniter, appears to be growing fast.

What really struck me about Laravel is there are a lot of passionate developers out there who insist this is THE way PHP must and will move forward (PHP 5.3+ (namespacing, etc.), modular libraries, and a lot of stuff I really don’t understand yet. And since I’m apparently very impressionable, I decided I should give it a go.

I’m not going to go into detail regarding the installation of Laravel, folder structure, or even what it takes to build a simple CRUD application (except maybe for Eloquent) because, frankly, anyone with a computer, an internet connection, and who can read should be able to do that with just about any popular framework with a little time and effort. Instead, I’ll focus on what has stood out to me so far in the few weeks I’ve been using Laravel.

Routes

Both Codeigniter and CFWheels use “implicit” routing. Create a controller and a controller action (i.e., “/users/create”) and you can route to it with any extra configuration. Laravel uses “explicit” routing (though you can make routes implicit by using

Route::controller(Controller::detect());

in the routes.php file, but I’ve read that’s a bad idea for some reason).

This seems like extra work, and it is. But the benefits are worth it. Not only do I see a summary of my entire application in one place, I can group routes for use with filters and even declare entire controllers instead of individual controller actions when it makes sense (see below).

//Home
Route::get('/','[email protected]');

//Auth
Route::post('login','[email protected]');
Route::get('logout', array('as' => 'logout', 'uses' => '[email protected]'));

Route::group(array('before' => 'auth'), function()
{
        Route::controller(array(
                'chores',
                'users'
                ));
});

Another thing I like about Laravel routes is that I can create a route, write some code, and then return something without having to write a controller action at all. This is great for running little tests. You could even call your views here and put the entire application in routes.php if you really wanted.

Route::get('test', function()
{
return eloquent_to_json(Chore::get());
});

Artisan

One of the advantages of PHP is the ability to run php scripts from the command line. Laravel has something called Artisan that comes with its own commands, as well as user-created scripts called “tasks” that can take advantage of Laravel’s ecosystem (Eloquent, etc.).

I’ve primarily used Artisan for running Migrations. Migrations are one of those development practices that I never really saw the value of. It just seemed easier for me to create and update the db schema via a MySQL client like Sequel Pro. However, I thought I’d give them a try with Laravel and I’ve discovered a couple of scenarios already where Migrations have proven to be very helpful (though I’m not sure if either one was an intended benefit):

  1. Early on in a web dev project, I find my self wanting to just wipe the data in the db without losing the schema itself. One way to do this is to make structure-only backups each time you update the schema which would be a hassle. With laravel migrations, I can just run “php artisan migrate:reset”, then run “php artisan migrate” to recreate the schema. If you need to always have a user to log into your app with, include that user record insert as one of your migrations.
  2. When you deploy an app, either the first time or for subsequent updates, you can run “php artisan migrate” on the remote server and ensure that the db environments are in sync (in terms of the schema). You can even add the migrate command to a git hook or something like Pagodabox’s Boxfile (more info.) to further automate the process.

Eloquent

Eloquent is Laravel’s ORM. It reminds me a lot of the only other ORM I’ve used in CFWheels.

Basically, you can do this (and much more):

$users = User::with('role','group')->get();

Instead of something like this (using laravels Fluent query builder):

$users = DB::table('users')
->left_join('roles','users.role_id','=','roles.id')
->left_join('groups','users.group_id','=','teams.id')
->get(array('users.*','roles.name AS role_name','teams.name AS team_name'));

All you have to do is create the model files for each table, and within those files, set up the relationships (one-to-one, one-to-many, etc.) between the tables.


This is really only scratching the surface of what makes laravel so attractive, and it will only get better with laravel 4. Hopefully, more and more developers will give it a look so that the community will keep getting stronger.