How-to: Laravel 4 tutorial; part 2 – orientation

[easyreview title=”Complexity rating” icon=”geek” cat1title=”Level of experience required, to follow this how-to.” cat1detail=”This series really is for web programmers only, though not a great deal of prior experience is required.” cat1rating=”3.5″ overall=”false”]

Laravel Tutorials

Signpost at North Point, Barbados, Feb.1998

I’ve used CodeIgniter for many years, but I have always, I confess, proceeded knowing just enough to get by. So forgive me if my approach seems a little clunky. I have never, for example, used CodeIgniter’s routes. I like my web application files nicely categorised into Model, View, Controller, Library and, if absolutely necessary, Helper. (Google an MVC primer if you’re not familar with these terms. These are concepts that will really aid your web development.)


So for now, I want to carry on using Controllers, if that’s okay with you. Controllers are stored under app/controllers. To anyone coming from CodeIgniter, that’s probably going to sound familiar!

As I go through the editions of this tutorial, I will be creating a small application that scrapes data from another website and represents it. More on that anon. Bearing that in mind, here’s a sample controller:

In CodeIgniter, that’s all you would have needed to do, due to automatic routing. In Laravel, you need also to add the following to app/routes.php:

Route::controller('scrape', 'ScrapeController');

To view these pages, you just visit yourdomain/scrape (/index is implied) and yourdomain/scrape/node/x (where x will probably refer to a specific node, possibly by database id).

This all bears explanation; the controllers page in the Laravel documentation does not currently expand on this. The names of the functions in the controller are significant. The first part of the camelCase style name is the HTTP verb that will be used to access the page. This may be an unfamiliar concept, but it’s great once you get used to it.

Most web pages will be accessed by the browser using the HTTP method “GET”. This is just the default. If you’re sending form data (you’ve clicked on a submit button), the chances are we’re dealing with the HTTP method “POST”. This makes it very easy to respond appropriately based on how the URL was reached.

Note: this is scratching the surface of RESTful web development. You may have heard the term bandied about. Wikipedia‘s not a bad place to start if you want to learn more about this.

We’ll reach the getIndex() function if we simply browse to /scrape. Following the age-old convention, “Index” is the default. If we browse to /scrape/node, the getNode() function comes into play. That function is expecting a single parameter, which would be passed along with the URL: /scrape/node/1.

You only reach the pages though through the magic of routing. In the Route::controller('scrape', 'ScrapeController');, we’re telling Laravel that calls to the URL /scrape need to be handed to the ScrapeController class.


Views are pretty straightforward and similar to CodeIgniter. Place them in app/views. Extending the example above, our controller could now look like this:

		return View::make('node', $data);


The second paramater in View::make is the data (typically a multi-dimensional array) sent to that view. Note that data can also be passed through to a view like this:

	public function getNode($node) {
		return View::make('node', $data)
		    ->with('node' => $node);

And then your view (app/views/node.php) could be like this:


This is node .

Obviously your real views will be more syntactically complete. You can see that the array is flattened one level so that $data('node'); in the controller is accessed a $node in the view.


Models are created under app/models. Unlike CodeIgniter, Laravel comes with its own object relational mapper. In case you’ve not encountered the concept before, an ORM gives you a convenient way of dealing with database tables as objects, rather than merely thinking in terms of SQL queries. CodeIgniter has plenty of ORMs, by the way, it just doesn’t ship with one as standard.

Laravel’s built-in ORM is called “Eloquent”. If you choose to use it (there are others available), when creating a model, you extend the Eloquent class. Eloquent makes some assumptions:

  • Each table contains a primary key called id.
  • Each Eloquent model is named in the singular, while the corresponding table is named in the plural. E.g. table name “nodes”; Eloquent model name “node”.

You can override this behaviour if you like, it just makes things a bit more convenient in many cases.

Example model app/models/node.php:

(You can omit the closing ?> tag.)

Because the Eloquent class already contains a lot of methods, you do not necessarily need to do more than this. In your controllers, you could for example now do this:

$nodes = Node::all();

foreach ($nodes as $node) {
  // Do stuff here

This is a whistle-stop tour preparatory to building a real application. Head on over to the official Laravel documentation for much more on all this.

Signposts image copyright © Andrea_44, licensed under Creative Commons. Used with permission.

8 Replies to “How-to: Laravel 4 tutorial; part 2 – orientation”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.