Thursday, October 30, 2014

Laravel 4 – simple website with backend tutorial – Part 1

Laravel 4 – simple website with backend tutorial – Part 1

85 Comments
Getting started with Laravel
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInShare on RedditShare on StumbleUpon
Laravel 4 app will be developed at the same time as writing this article, and everything will be up on Github. I’ll try to separate the tutorial parts in branches so it will be easier to follow. Github URL: https://github.com/bstrahija/l4-site-tutorial
EDIT: The second part of Laravel 4 tutorial is available!!!
This is by no means a tutorial for beginners, there are plenty of those ;) I assume you already know the basics on how to install Composer, pull down the Laravel 4 base application. You will need some mid-level knowledge on tools like Composer, Git, working in the terminal
I’m going to put up some links to resources on getting started with Laravel and Composer at the end of this article. Also keep in mind that at this point Laravel 4 is still in BETA, but it’s really stable and scheduled for release during May.

Installing Laravel 4 and all the dependencies

Since Laravel 4 already leverages a lot of third party packages, we’ll expand on that, and add some that could be useful for our application. Here are some of composer packages that we’re going to need:
  • Sentry – user authentication (cartalyst/sentry)
  • Imagine – image manipulation and resizing (imagine/Imagine)
  • Markdown – for converting markdown text to HTML (dflydev/markdown)
So, first let’s start by creating a new L4 app. We’re going to call our app simply “L4 Site”. You can call yours anything you like ;)
1
2
git clone -b develop git://github.com/laravel/laravel.git l4_site
cd l4_site
The next step is to setup our composer file. After adding our dependencies, it should look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{
    "require": {
        "laravel/framework": "4.0.*",
        "cartalyst/sentry": "2.0.*",
        "dflydev/markdown": "v1.0.2",
        "imagine/Imagine": "v0.4.1"
    },
    "autoload": {
        "classmap": [
            "app/commands",
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/database/seeds",
            "app/tests/TestCase.php"
        ]
    },
    "scripts": {
        "post-update-cmd": "php artisan optimize"
    },
    "config": {
        "preferred-install": "dist"
    },
    "minimum-stability": "dev"
}
Then just run “php composer install” and wait for all the dependencies to download. This could take a couple of minutes.
When everything is finished downloading we need to check if the app actually works. For this I would recommend to setup a virtual host entry, or if you working on a machine with PHP 5.4 you can utilize the PHP built in server by running “php artisan serve” from the console.
For simplicity sake I’ll take the approach with the build in PHP server which will start the server on the URL http://localhost:8000/.
If you get the Hello World! page then everything is fine, but if you see any errors you should consult the Laravel 4 documentation.

Setup the database and migrations

The next step is to setup the database connection and create our migrations. I’ll be working with a MySQL database, but you can choose whatever database type you want as long as Laravel 4 supports it. If don’t know what migrations and seeding are, you can read more on that here: http://four.laravel.com/docs/migrations
My database is named “l4_site”, and now I am going to enter the database credentials into the database configuration file (app/config/database.php). This is pretty straightforward, but if you run into problems consult the Laravel 4 documentation.
Since we’re leveraging the Sentry package for our user authentication stuff, and Sentry already has some migration setup, we just need to run those migrations by running the following command in our console:
1
php artisan migrate --package=cartalyst/sentry
Sentry should create 4 DB tables: users, groups, users_groups and throttle. To complete installation for the Sentry package consult the Sentry docs: http://docs.cartalyst.com/sentry-2/installation/laravel-4
EDIT: Some people complained there’s not enough info on installing Sentry, so basicaly you need to add the service provider and the alias to your app/config/app.php file:
1
'Cartalyst\Sentry\SentryServiceProvider'
and
1
'Sentry' => 'Cartalyst\Sentry\Facades\Laravel\Sentry',
I hope this clears it up.
Now that we have our authentication tables setup, we need to create tables that will contain the actual content. We will have 2 types of content entries, articles and pages. So the migrations that we need are these:
1
2
php artisan migrate:make create_articles_table --table=articles --create
php artisan migrate:make create_pages_table --table=pages --create
The migrations are created inside the directory “app/database/migrations“. To keep things simple, these are my migrations.
Articles:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
 
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
 
class CreateArticlesTable extends Migration {
 
    public function up()
    {
        Schema::create('articles', function(Blueprint $table)
        {
            $table->increments('id');
            $table->string('title');
            $table->string('slug');
            $table->text('body')->nullable();
            $table->string('image')->nullable();
            $table->integer('user_id');
            $table->timestamps();
        });
    }
 
    public function down()
    {
        Schema::drop('articles');
    }
}
and Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?php
 
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
 
class CreatePagesTable extends Migration {
 
    public function up()
    {
        Schema::create('pages', function(Blueprint $table)
        {
            $table->increments('id');
            $table->string('title');
            $table->string('slug');
            $table->text('body')->nullable();
            $table->integer('user_id');
            $table->timestamps();
        });
    }
 
    public function down()
    {
        Schema::drop('pages');
    }
}
Now just run “php artisan migrate” and the tables are created. It’s magic :)

Our models

To actually work with the database we need to create our models. The models that we need are:
app/models/Article.php
1
2
3
4
5
6
7
8
9
10
11
12
<?php namespace App\Models;
 
class Article extends \Eloquent {
 
    protected $table = 'articles';
 
    public function author()
    {
        return $this->belongsTo('User');
    }
 
}
app/models/Page.php
1
2
3
4
5
6
7
8
9
10
11
12
<?php namespace App\Models;
 
class Page extends \Eloquent {
 
    protected $table = 'pages';
 
    public function author()
    {
        return $this->belongsTo('User');
    }
 
}
There’s already a default User model in the “app/models” folder, I just like to namespace it like the others under App\Models. Go ahead and check it out at: https://github.com/bstrahija/l4-site-tutorial/blob/master/app/models/User.php

Seeding the database

For the app to actually contain some data, I like to add some dummy content. This can be achieved easily by using the Laravel 4 seeds. The files should be located in the “app/database/seeds” directory, and here my setup for the app:
app/database/seeds/DatabaseSeeder.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
 
class DatabaseSeeder extends Seeder {
 
    public function run()
    {
        $this->call('SentrySeeder');
        $this->command->info('Sentry tables seeded!');
 
        $this->call('ContentSeeder');
        $this->command->info('Content tables seeded!');
    }
 
}
EDIT: Since we use the Sentry package I changed the way the user is created. We now use
1
Sentry::getUserProvider()->create();
for creation.
Also note that the User model is namespaced under App\Models, so you should also update you default model. Just take a look at everything here: https://github.com/bstrahija/l4-site-tutorial/blob/master/app/models/User.php
app/database/seeds/SentrySeeder.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?php
 
use App\Models\User;
 
class SentrySeeder extends Seeder {
 
    public function run()
    {
        DB::table('users')->delete();
        DB::table('groups')->delete();
        DB::table('users_groups')->delete();
 
        Sentry::getUserProvider()->create(array(
            'email'       => 'admin@admin.com',
            'password'    => "admin",
            'first_name'  => 'John',
            'last_name'   => 'McClane',
            'activated'   => 1,
        ));
 
        Sentry::getGroupProvider()->create(array(
            'name'        => 'Admin',
            'permissions' => array('admin' => 1),
        ));
 
        // Assign user permissions
        $adminUser  = Sentry::getUserProvider()->findByLogin('admin@admin.com');
        $adminGroup = Sentry::getGroupProvider()->findByName('Admin');
        $adminUser->addGroup($adminGroup);
    }
 
}
app/database/seeds/ContentSeeder.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<?php
 
use App\Models\Article;
use App\Models\Page;
 
class ContentSeeder extends Seeder {
 
    public function run()
    {
        DB::table('articles')->delete();
        DB::table('pages')->delete();
 
        Article::create(array(
            'title'   => 'First post',
            'slug'    => 'first-post',
            'body'    => 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.',
            'user_id' => 1,
        ));
 
        Page::create(array(
            'title'   => 'About us',
            'slug'    => 'about-us',
            'body'    => 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.',
            'user_id' => 1,
        ));
    }
 
}
Now run “php artisan db:seed” in the console, and your database will be populated with the dummy data from the seeds. Nice.

Extra tip on database seeding

I created a couple of custom artisan commands to refresh the app. You can check them out: https://github.com/bstrahija/l4-site-tutorial/tree/master/app/commands
This is useful for me when working on the app, and sometimes the data is modified, or some entries are deleted. Then I can easily reset the database to a fresh state by running:
1
php artisan app:refresh
Also, since the migrate command doesn’t migrate 3rd party packages, I added the Sentry migration to the command.
You can add your own commands, call other package migrations etc.

Tinker with our models

Laravel 4 comes with a nice tool for tinkering with out app.
What we can do now is test if the database was properly seeded. Just run “php artisan tinker” and we get into a simple REPL for our app.
Now to check if our pages and articles were seeded we just run the following inside the REPL:
1
echo App\Models\Page::all();
or
1
echo App\Models\Article::all();
And for each command we should get our database content entries in JSON format.

What is next?

For now we just created our database and models, added some dummy data to the database, and there isn’t really much to see in the browser yet.
In the next part we will start to create our backend panel so prepare yourself for some working with routes, controllers, views and assets.
The backend will be built with the Twitter Bootstrap package, since I find it’s the easiest to integrate.

Monday, October 27, 2014

25 Laravel Tips and Tricks

25 Laravel Tips and Tricks

by 1 Comment
Gift
Want a free year on Tuts+ (worth $180)? Start an InMotion Hosting plan for $3.49/mo.
There was a period of time, not too long ago, when PHP and its community were, for lack of better words, hated. Seemingly, the headline joke of every day was one that related to how terrible PHP was. Let's see, what new PHP-slamming blog article will be posted today?
Yes, sadly enough, the community and ecosystem simply weren't on the same level as other modern languages.
Yes, sadly enough, the community and ecosystem simply weren't on the same level as other modern languages. It seemed that PHP was destined to live out its dominating lifespan in the form of messy WordPress themes.
But, then, quite amazingly, things began to change - and quickly, too. Like a witch stirring the pot, innovative new projects began popping out of nowhere. Perhaps most notable of these projects was Composer: PHP's definitive dependency manager (not unlike Ruby's Bundler or Node's NPM). While, in the past, PHP developers were forced to wrangle PEAR into shape (a nightmare, indeed), now, thanks to Composer, they can simply update a JSON file, and immediately pull in their desired dependency. A profiler here, a testing framework there... all in seconds!
In the crowded PHP framework world, just as CodeIgniter began to fizzle out, Taylor Otwell's Laravel framework arose out of the ashes to become the darling of the community. With such a simple and elegant syntax, building applications with Laravel and PHP was - gasp - downright fun! Further, with version 4 of the framework leveraging Composer heavily, things finally seemed to be falling into place for the community.

Want migrations (version control for your database)? Done. How about a powerful Active-Record implementation? Sure, Eloquent will do the trick quite nicely. What about testing facilities? Of course. And routing? Most certainly. What about a highly tested HTTP layer? Thanks to Composer, Laravel can leverage many of the excellent Symfony components. When it comes right down to it, chances are, if you need it, Laravel offers it.

While PHP used to be not dissimilar from a game of Jenga - just one block and away from falling to pieces - suddenly, thanks to Laravel and Composer, the future couldn't look any brighter. So pull out some shades, and dig into all that the framework has to offer.
Laravel offers one of the most powerful Active-Record implementations in the PHP world. Let's say that you have an orders table, along with an Order Eloquent model:
1
class Order extends Eloquent {}
We can easily perform any number of database queries, using simple, elegant PHP. No need to throw messy SQL around the room. Let's grab all orders.
1
$orders = Order::all();
Done. Or maybe, those orders should be returned in order, according to the release date. That's easy:
1
$orders = Order::orderBy('release_date', 'desc')->get();
What if, rather than fetching a record, we instead need to save a new order to the database. Sure, we can do that.
1
2
3
$order = new Order;
$order->title = 'Xbox One';
$order->save();
Finished! With Laravel, tasks that used to be cumbersome to perform are laughably simple.
Laravel is unique in that it can be used in a number of ways. Prefer a simpler, more Sinatra-like routing system? Sure, Laravel can offer that quite easily, using closures.
1
2
3
4
5
Route::get('orders', function()
{
    return View::make('orders.index')
        ->with('orders', Order::all());
});
This can prove helpful for small projects and APIs, but, chances are high that you'll require controllers for most of your projects. That's okay; Laravel can do that, too!
1
Route::get('orders', 'OrdersController@index');
Done. Notice how Laravel grows with your needs? This level of accomodation is what makes the framework as popular as it is today.
What do we do in the instances when we must define relationships? For example, a task will surely belong to a user. How might we represent that in Laravel? Well, assuming that the necessary database tables are setup, we only need to tweak the related Eloquent models.
01
02
03
04
05
06
07
08
09
10
11
12
13
class Task extends Eloquent {
    public function user()
    {
        return $this->belongsTo('User');
    }
}
 
class User extends Eloquent {
    public function tasks()
    {
        return $this->hasMany('Task');
    }
}
And, with that, we're done! Let's grab all tasks for the user with an id of 1. We can do that in two lines of code.
1
2
$user = User::find(1);
$tasks = $user->tasks;
However, because we've defined the relationship from both ends, if we instead want to fetch the user associated with a task, we can do that, too.
1
2
$task = Task::find(1);
$user = $task->user;
Often, it can be helpful to link a form to a model. The obvious example of this is when you wish to edit some record in your database. With form model binding, we can instantly populate the form fields with the values from the associated table row.
01
02
03
04
05
06
07
08
09
10
11
{{ Form::model($order) }}
    <div>
        {{ Form::label('title', 'Title:') }}
        {{ Form::text('title') }}
    </div>
 
    <div>
        {{ Form::label('description', 'Description:') }}
        {{ Form::textarea('description') }}
    </div>
{{ Form::close() }}
Because the form is now linked to a specific Order instance, the inputs will display the correct values from the table. Simple!
Too many database queries, and, very quickly, your application can become like molasses. Luckily, Laravel offers a simple mechanism for caching these queries, using nothing more than a single method call.
Let's grab all questions from the database, but cache the query, since it's not likely that this table will be updated frequently.
1
$questions = Question::remember(60)->get();
That's it! Now, for the next hour of pages requests, that query will remain cached, and the database will not be touched.
You'll encounter situations when multiple views require a certain variable or piece of data. A good example of this is a navigation bar that displays a list of tags.
Too keep controllers as minimal as possible, Laravel offers view composers to manage things like this.
1
2
3
4
View::composer('layouts.nav', function($view)
{
    $view->with('tags', ['tag1', 'tag2']);
});
With this piece of code, any time that the layouts/nav.blade.php view is loaded, it will have access to a variable, $tags, equal to the provided array.
Laravel takes a dead-simple approach to authentication. Simply pass an array of credentials, likely fetched from a login form, to Auth::attempt(). If the provided values match what is stored in the users table, the user will instantly be logged in.
01
02
03
04
05
06
07
08
09
10
$user = [
    'email' => 'email',
    'password' => 'password'
];
 
if (Auth::attempt($user))
{
    // user is now logged in!
    // Access user object with Auth::user()
}
What if we need to log the user out - perhaps, when a /logout URI is hit? That's easy, too.
1
2
3
4
5
6
Route::get('logout', function()
{
    Auth::logout();
     
    return Redirect::home();
});
Working RESTfully in Laravel has never been easier. To register a resourceful controller, simple call Route::resource(), like so:
1
Route::resource('orders', 'OrdersController');
With this code, Laravel will register eight routes.
  • GET /orders
  • GET /orders/:order
  • GET /orders/create
  • GET /orders/:order/edit
  • POST /orders
  • PUT /orders/:order
  • PATCH /orders/:order
  • DELETE /orders/:order
Further, the companion controller may be generated from the command line:
1
php artisan controller:make OrdersController
Within this generated controller, each method will correspond to one of the routes above. For examples, /orders will map to the index method, /orders/create will map to create, etc.
We now have the necessary power to build RESTful applications and APIs with ease.
While, yes, PHP is by nature a templating language, it hasn't evolved to become an overly good one. That's okay, though; Laravel offers its Blade engine to fill the gap. Simply name your views with a .blade.php extension, and they will automatically be parsed, accordingly. Now, we can do such things as:
1
2
3
4
5
6
7
@if ($orders->count())
    <ul>
        @foreach($orders as $order)
            <li>{{ $order->title }}</li>
        @endforeach
    </ul>
@endif
Because Laravel makes use of Composer, we instantly have PHPUnit support in the framework out of the box. Install the framework and run phpunit from the command line to test it out.
Even better, though, Laravel offers a number of test helpers for the most common types of functional tests.
Let's verify that the home page returns a status code of 200.
1
2
3
4
5
public function test_home_page()
{
    $this->call('GET', '/');
    $this->assertResponseOk();
}
Or maybe we want to confirm that, when a contact form is posted, the user is redirected back to the home page with a flash message.
01
02
03
04
05
06
07
08
09
10
11
12
public function test_contact_page_redirects_user_to_home_page()
{
    $postData = [
        'name' => 'Joe Example',
        'email' => 'email-address',
        'message' => 'I love your website'
    ];
 
    $this->call('POST', '/contact', $postData);
 
    $this->assertRedirectedToRoute('home', null, ['flash_message']);
}
As part of Laravel 4.1 - scheduled to be released in November, 2013 - you can easily write an Artisan command to SSH into your server, and perform any number of actions. It's as simple as using the SSH facade:
1
2
3
4
SSH::into('production')->run([
    'cd /var/www',
    'git pull origin master'
]);
Pass an array of commands to the run() method, and Laravel will handle the rest! Now, because it makes sense to execute code like this as an Artisan command, you only need to run php artisan command:make DeployCommand, and insert the applicable code into the command's fire method to rapidly create a dedicated deployment command!
Laravel offers an elegant implementation of the observer pattern that you may use throughout your applications. Listen to native events, like illuminate.query, or even fire and catch your own.
A mature use of events in an application can have an incredible effect on its maintainability and structure.
1
2
3
4
5
Event::listen('user.signUp', function()
{
    // do whatever needs to happen
    // when a new user signs up
});
Like most things in Laravel, if you'd instead prefer to reference a class name, rather than a closure, you can freely do so. Laravel will then resolve it out of the IoC container.
1
Event::listen('user.signUp', 'UserEventHandler');

As an application grows, it can be difficult to view which routes have been registered. This is especially true if proper care has not been given to your routes.php file (i.e. abusive implicit routing).
Laravel offers a helpful routes command, which will display all registered routes, as well as the controller methods that they trigger.
1
php artisan routes
Think about when a user signs up for your application. Likely, a number of events must take place. A database table should be updated, a newsletter list should be appended to, an invoice must be raised, a welcome email might be sent, etc. Unfortunately, these sorts of actions have a tendency to take a long time.
Why force the user to wait for these actions, when we can instead throw them into the background?
1
Queue::push('SignUpService', compact('user'));
Perhaps the most exciting part, though, is that Laravel brilliantly offers support for Iron.io push queues. This means that, even without an ounce of "worker" or "daemon" experience, we can still leverage the power of queues. Simply register a URL end-point using Laravel's helpful php artisan queue:subscribe command, and Iron.io will ping your chosen URL each time a job is added to the queue.

Simple steps to faster performance!
When validation is required (and when isn't it), Laravel again comes to the rescue! Using the Validator class is as intuitive as can be. Simply pass the object under validation, as well as a list of rules to the make method, and Laravel will take care of the rest.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
$order = [
    'title' => 'Wii U',
    'description' => 'Game console from Nintendo'
];
 
$rules = [
    'title' => 'required',
    'description' => 'required'
];
 
$validator = Validator::make($order, $rules);
 
if ($validator->fails())
{
    var_dump($validator->messages()); // validation errors array
}
Typically, this type of code will be stored within your model, meaning that validation of, say, an order could be reduced to a single method call:
1
$order->isValid();

Especially when first learning Laravel, it an be helpful to tinker around with the core. Laravel's tinker Artisan command can help with this.
As part of version 4.1, the tinker command is even more powerful, now that it leverages the popular Boris component.
1
2
3
4
5
$ php artisan tinker
 
> $order = Order::find(1);
> var_dump($order->toArray());
> array(...)
Think of migrations as version control for your database. At any given point, you may "rollback" all migrations, rerun them, and much more. Perhaps the true power rests in the power to push an app to production, and run a single php artisan migrate command to instantly construct your database.
To prepare the schema for a new users table, we may run:
1
php artisan migrate:make create_users_table
This will generate a migration file, which you may then populate according to your needs. Once complete, php artisan migrate will create the table. That's it! Need to roll back that creation? Easy! php artisan migrate:rollback.
Here's an example of the schema for a frequently asked questions table.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
public function up()
{
    Schema::create('faqs', function(Blueprint $table) {
        $table->integer('id', true);
        $table->text('question');
        $table->text('answer');
        $table->timestamps();
    });
}
 
public function down()
{
    Schema::drop('faqs');
}
Notice how the drop() method performs the inverse of up(). This is what allows us to rollback the migration. Isn't that a lot easier that wrangling a bunch of SQL into place?
While Laravel offers a number of helpful generators, an incredibly helpful third-party package, called "Laravel 4 Generators," takes this even further. Generate resources, seed files, pivot tables, and migrations with schema!
In this previous tip, we were forced to manually write the schema. However, with the generators package enabled, we can instead do:
1
php artisan generate:migration create_users_table --fields="username:string, password:string"
The generator will take care of the rest. This means that, with two commands, you can prepare and build a new database table.
Laravel 4 Generators may be installed through Composer.
As noted earlier, there are number of instances when it can be helpful to write custom commands. They can be used to scaffold applications, generate files, deploy applications, and everything in between.
Because this is such a common task, Laravel makes the process of creating a command as easy as it can be.
1
php artisan command:make MyCustomCommand
This command will generate the necessary boilerplate for your new custom command. Next, from the newly created, app/commands/MyCustomCommand.php, fill the appropriate name and description:
1
2
protected $name = 'command:name';
protected $description = 'Command description.';
And, finally, within the command class' fire() method, perform any action that you need to. Once finished, the only remaining step is to register the command with Artisan, from app/start/Artisan.php.
1
Artisan::add(new MyCustomCommand);
Believe it or not; that's it! You may now call your custom command from the terminal.
Laravel leverages the facade pattern heavily. This allows for the clean static-like syntax that you'll undoubtedly come to love (Route::get(), Config::get(), etc.), while still allowing for complete testability behind the scenes.
Because these "underlying classes" are resolved out of the IoC container, we can easily swap those underlying instances out with mocks, for the purposes of testing. This allows for such control as:
1
Validator::shouldReceive('make')->once();
Yep, we're calling shouldReceive directly off of the facade. Behind the scenes, Laravel makes use of the excellent Mockery framework to allow for this. This means that you may freely use these facades in your code, while still allowing for 100% testability.
Because building forms can frequently be a cumbersome task, Laravel's form builder steps in to ease the process, as well as leverage many of the idiosyncrasies related to form construction. Here are a few examples:
1
2
3
4
5
{{ Form::open() }}
    {{ Form::text('name') }}
    {{ Form::textarea('bio') }}
    {{ Form::selectYear('dob', date('Y') - 80, date('Y')) }}
{{ Form::close() }}
What about tasks, such as remembering input from the previous form submission? Laravel can do all of that automatically!
At the core of Laravel is its powerful IoC container, which is a tool that assists in managing class dependencies. Notably, the container has the power to automatically resolve classes without configuration!
Simply typehint your dependencies within the constructor, and, upon instantiation, Laravel will use PHP's Reflection API to intelligently read the typehints, and attempt to inject them for you.
1
2
3
4
public function __construct(MyDependency $thing)
{
    $this->thing = $thing;
}
As long as you request the class out of the IoC container, this resolution will take place automatically.
1
$myClass = App::make('MyClass');
An important note is that controllers are always resolved out of the IoC container. As such, you may free typhint your controller's dependencies, and Laravel will subsequently do its best to inject them for you.
While a single environment might work for small projects, for any applications of size, multiple environments will prove essentials. Development, testing, production...all of these are essential and require their own configuration.
Maybe your test environment uses a database in memory for testing. Maybe your development environment uses different API keys. Likely, your production environment will use a custom database connection string.
Luckily, Laravel makes our job simple once again. Have a look at bootstrap/start.php in your app.
Here's a basic demonstration of setting both a local and production environment, based upon the browser's address bar.
1
2
3
4
$env = $app->detectEnvironment(array(
    'local' => array('localhost'),
    'production' => array('*.com')
));
While this will work, generally speaking, it's preferred to use environment variables for this sort of thing. No worries; this is still doable in Laravel! Instead, simply return a function from the detectEnvironment method on the container object.
1
2
3
4
$env = $app->detectEnvironment(function()
{
    return getenv('ENV_NAME') ?: 'local';
});
Now, unless an environment variable has been set (which you will do for production), the environment will default to local.
Advertisement
Laravel, yet again, takes a dead-simple approach to configuration. Create a folder within app/config that matches your desired environment, and any configuration files within it will take precedence, if the environment name matches. As such, to, say, set a different billing API key for development, you could do:
1
2
3
4
5
<?php app/config/development/billing.php
 
return [
    'api_key' => 'your-development-mode-api-key'
];
The configuration switcharoo is automatic. Simply type Config::get('billing.api_key'), and Laravel will correctly determine which file to read from.
When it comes to education, the Laravel community, despite its relatively young age, is a never-ending well. In little over a year, a half-dozen different books - related to all matters of Laravel development - have been released.