Category: Tutorials

MVC for Noobs

Model-View-Controller (MVC) is probably one of the most quoted patterns in the web programming world in recent years. Anyone currently working in anything related to web application development will have heard or read the acronym hundreds of times. Today, we’ll clarify what MVC means, and why it has become so popular.

Ancient History…

MVC is not a design pattern, it is an Architectural pattern that describes a way to structure our application and the responsibilities and interactions for each part in that structure.

It was first described in 1979 and, obviously, the context was a little bit different. The concept of web application did not exist. Tim Berners Lee sowed the seeds of World Wide Web in the early nineties and changed the world forever. The pattern we use today for web development is an adaptation of the original pattern.

The wild popularization of this structure for web applications is due to its inclusion in two development frameworks that have become immensely popular: Struts and Ruby on Rails. These two environments marked the way for the hundreds of frameworks created later.

MVC for Web Applications

The idea behind the Model-View-Controller architectural pattern is simple: we must have the following responsibilities clearly separated in our application:

The application is divided into these three main components, each one in charge of different tasks. Let’s see a detailed explanation and an example.

Controller

The Controller manages the user requests (received as HTTP GET or POST requests when the user clicks on GUI elements to perform actions). Its main function is to call and coordinate the necessary resources/objects needed to perform the user action. Usually the controller will call the appropriate model for the task and then selects the proper view.

Model

The Model is the data and the rules applying to that data, which represent concepts that the application manages. In any software system, everything is modeled as data that we handle in a certain way. What is a user, a message or a book for an application? Only data that must be handled according to specific rules (date can not be in the future, e-mail must have a specific format, name cannot be more than x characters long, etc).

The model gives the controller a data representation of whatever the user requested (a message, a list of books, a photo album, etc). This data model will be the same no matter how we may want to present it to the user, that’s why we can choose any available view to render it.

The model contains the most important part of our application logic, the logic that applies to the problem we are dealing with (a forum, a shop, a bank, etc). The controller contains a more internal-organizational logic for the application itself (more like housekeeping).

View

The View provides different ways to present the data received from the model. They may be templates where that data is filled. There may be several different views and the controller has to decide which one to use.

A web application is usually composed of a set of controllers, models and views. The controller may be structured as a main controller that receives all requests and calls specific controllers that handles actions for each case.

Let’s See an Example

Suppose we’re developing an online book store. The user can perform actions such as: view books, register, buy, add items to current order, create or delete books (if he is an administrator, etc.). Let’s see what happens when the user clicks on the fantasy category to view the titles we have available.

We will have a particular controller to handle all books-related actions (view, edit, create, etc). Let’s call it books_controller.php for this example. We will also have a model, for example book_model.php, handling data and logic related to the items in the shop. Finally we will have a series of views to present, for example, a list of books, a page to edit books, etc.

The following figure shows how the user request to view the fantasy books list is handled:

The controller (books_controller.php) receives the user request [1] as an HTTP GET or POST request (we can also have a central controller, for example index.php receiving it and then calling books_controller.php).

The controller examines the request and the parameters and calls the model (book_model.php) asking him to return the list of available fantasy books [2].

The model is responsible for getting that information from the database (or wherever it is stored) [3], apply filters or logic if necessary, and return the data representing the list of books [4].

The controller will use the appropriate view [5] to present these data to the user [6-7]. If the request came from a mobile phone, a view for mobile phones will be used, if the user has a particular skin selected, the corresponding view will be chosen, and so on.

What are the Advantages?

The most obvious advantage we gain using MVC is a clear separation of presentation (the interface with the user) and application logic.

Support for different types of users using different types of devices is a common problem these days. The interface presented must be different if the request came from a desktop computer or from a cell phone. The model returns exactly the same data, the only difference is that the controller will choose a different view to render them (we can think of a different template).

Apart from isolating the view from the business logic, the M-V-C separation reduces the complexity when designing large applications. The code is much more structured and therefore easier maintain, test and reuse.

Ok, but Why a Framework?

When you use a framework, the basic structure for MVC is already prepared and you just have to extend that structure, placing your files in the appropriate directory, to comply with the Model-View-Controller pattern. Also you get a lot of functionality already written and thoroughly tested.

Take cakePHP as an example MVC framework. Once you have it installed, you’ll see three main directories:

• app/
• cake/
• vendors/

The app folder is where you place your files. It is your place to develop your part of the application.

The cake folder is where cakePHP has its files and where they have developed their part (main framework functionality).

The vendors folder is for third-party PHP libraries if needed.

Your working place (app directory) has the following structure:

• app/
  • config/
  • controllers/
  • locale/
  • models/
  • plugins/
  • tests/
  • tmp/
  • vendors/
  • views/
  • webroot/

Now you have to put your controllers in the controllers directory, your models in the models directory and your views in… the views directory!

Once you get used to your framework, you’ll be able to know where to look for almost any piece of code you need to modify or create. This organization alone makes maintainability a lot easier.

Let’s Framework our Example

Since this tutorial is not intended to show you how to create an application using cakePHP, we’ll use it only to show example code for the model, view and controller components and comment on the benefits of using an MVC framework. The code is oversimplified and not suitable for real applications.

Remember we had a book store and a curious user who wants to see the complete list of books in the fantasy category. We said that the controller will be the one receiving the request and coordinating the necessary actions.

So, when the user clicks, the browser will be requesting this url:

 www.ourstore.com/books/list/fantasy

CakePHP likes to format URLs in the form /controller/action/param1/param2 , where action is the function to call within the controller. In the old classic url format it would be:

 www.ourstore.com/books_controller.php?action=list&category=fantasy

Controller

With the help of cakePHP framework, our controller will look something like this:

<?php

class BooksController extends AppController {

 function list($category) {

 $this->set('books', $this->Book->findAllByCategory($category));

 }

 function add() { ... ... }

 function delete() { ... ... }

 ... ... } ?>

Simple, isn’t it?. This controller will be saved as books_controller.php and placed in /app/controllers. It contains the list function, to perform the action in our example, but also other functions to perform other book-related actions (add a new book, delete a new book, etc).

The framework provides a lot of things for us and only one line is necessary to list the books. We have base classes with the basic controller behavior already defined, so we inherit from them (AppController which inherits from Controller).

All it has to do in the list action is call the model to get the data and then choose a view to present it to the user. Let’s explain how this is done.

this->Book is our Model, and this part:

 $this->Book->findAllByCategory($category) 

is telling the model to return the list of books in the selected category (we’ll see the model later).

The set method in the line:

 $this->set('books', $this->Book->findAllByCategory($category)); 

Is the controller way to pass data to the view. It sets the books variable to the data returned by the model and makes it accessible to the view.

Now we just have to render the view, but this will be done automatically by cakePHP if we want the default view. If we need any other view we just have to call it explicitly using the render method.

Model

The model is even more simple:

<?php

class Book extends AppModel { 

}

?>

Why empty? Because it inherits from a base class that provides necessary functionality and we have followed the CakePHP name conventions to allow the framework to do other tasks automatically. For example, cakePHP knows, based on names, that this model is used in BooksController and that it will access a database table called books.

With this declaration only we have a book model capable of reading, deleting or saving data from the database

The code will will be saved as book.php and placed in /app/models.

View

All we have to do now is creating a view (at least one) for the list action. The view will have the HTML code and a few (as few as possible) PHP lines to loop through the books array provided by the model.

<table> <tr> <th>Title</th> <th>Author</th> <th>Price</th> </tr>

<?php foreach ($books as $book): ?> <tr> <td> <?php echo $book['Book']['title']; ?> </td> <td> <?php echo $book['Book']['author']; ?> </td> <td> <?php echo $book['Book']['price']; ?> </td> </tr> <?php endforeach; ?>

</table>

As we can see, the view doesn’t produce a complete page, just an HTML fragment (a table in this case). This is because CakePHP provides another way to define the layout of the page, and the views are inserted into that layout. The framework also provides us with some helper objects to make common task easy when creating these HTML excerpts (insert forms, links, Ajax or JavaScript).

We make this the default view saving it as list.ctp ( list is the name of the action and ctp means cake template) and placing it in /app/views/books (inside books because these are views for books controller actions).

And this completes the three components with the help of CakePHP framework!

Conclusion

We have learned what is probably the most commonly used architectural pattern today. We must be aware though that when we talk about patterns in the programming world, we are talking about flexible frames, to be tailored to the particular problem at hand. We will find implementations introducing variations on the structure we have seen, but the important thing is that, in the end, the pattern helps us gain a clear division between responsibilities and better maintainability, code-reuse, and testing.

We have also seen the advantages of using an MVC framework that provides us with a basic MVC skeleton and a lot of functionality, improving our productivity and making the development process easier. Thanks for reading!

Quick Tip: Learning and Understanding CSS3 Gradients

Creating an image only for the purpose of displaying a gradient is inflexible, and is quickly becoming a bad practice. Unfortunately, at the time of this writing, they very well might still be required, but hopefully not for much longer. Thanks to Firefox and Safari/Chrome, we can now create powerful gradients with minimal effort. In this video quick tip, we’ll examine some of the differences in syntax when working with the -moz and -webkit vendor prefixes.

Webkit CSS3

While Mozilla and Webkit generally adopt the same syntax for CSS3 properties, they unfortunately don’t quite agree when it comes to gradients. Webkit was first to embrace gradients, and uses the following structure:

/* Syntax, taken from: http://webkit.org/blog/175/introducing-css-gradients/ */
-webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)

/* In practice... */
background: -webkit-gradient(linear, 0 0, 0 100%, from(red), to(blue));

Don’t worry if your eyes gloss over at that syntax; mine did too! Just note that we require a comma-separated list of parameters.

• What type of gradient? (linear)
• X and Y axis coordinates of where to begin. (0 0 – or left-top corner)
• X and Y axis coordinates of where to conclude (0 100% – or left-bottom corner)
• What color to begin with? (from(red))
• What color to conclude with? (to(blue))

Mozilla

Firefox, which implemented gradient support with version 3.6, prefers a slightly different syntax.

/* Syntax, taken from: http://hacks.mozilla.org/2009/11/css-gradients-firefox-36/ */
 -moz-linear-gradient( [<point> || <angle>,]? <stop>, <stop> [, <stop>]* )

/* In Practice */
background: -moz-linear-gradient(top, red, blue);

• Note how we’ve placed the type of gradient, linear, within the vendor extension.
• Where should the gradient begin? (top – we could also pass in degrees, as in -45deg)
• What color to start with? (red)
• What color to conclude with? (blue)

Color-Stops

What if you don’t need a 100% gradient from one color to another? This is where color stops come into play. A common design technique is to apply a short and subtle gradient, like this:

Note the subtle off-white to white gradient at the top.

In the past, the standard implementation was to create an image, set it as the background of an element, and set it to repeat horizontally. However, with CSS3, this is a cinch.

background: white; /* fallback for older/unsupporting browsers */
background: -moz-linear-gradient(top, #dedede, white 8%);
background: -webkit-gradient(linear, 0 0, 0 8%, from(#dedede), to(white));
border-top: 1px solid white;

This time, we set the gradient to conclude at 8%, rather than 100%, which is the default. Note that we’re also applying a border top to add contrast; this is very common.

If we wish to add a third (or Nth) color, we can do:

background: white; /* fallback for older/unsupporting browsers */
background: -moz-linear-gradient(top, #dedede, white 8%, red 20%);
background: -webkit-gradient(linear, 0 0, 0 100%, from(#dedede), color-stop(8%, white), color-stop(20%, red);

• With the -moz version, we designate that, at 20% of the element height, we should now be at the color red.
• For -webkit, we use color-stop, and pass in two parameters: where the stop should occur, and what the color should be.

Important Notes About CSS Gradients

• Use them as much as you can. If it’s okay to let IE users see a solid color, I encourage you to use this method.
• IE6/7/8, Opera, Safari 3, and Firefox 3 cannot render CSS3 gradients. Firefox and Safari users generally upgrade often, so that’s not as big of a deal.
• Always apply a default, solid color, background for browsers that won’t understand the vendor prefixes.
• Never use a red to blue gradient, as I did for the examples.
• Webpages don’t need to look the same in every browser!

Setting up a Rails Server and Deploying with Capistrano on Fedora from Scratch

This article and video tutorial will teach you how to setup a basic Fedora server for Rails and PostgreSQL deployments. First, we’ll setup Apache and PostgreSQL. Then, we’ll use phpPgAdmin to create our application’s user and databases. After that, we’ll setup the Ruby platform using Passenger to run our application. Once all the components are installed, we’ll prep our application for deployment using Capistrano.

I’ll show you how to use Capistrano to automate remote tasks and take advantage of other features.

On With The Show

Understanding the Deployment Process

There is always a lot of confusion around deploying Rails applications. This tutorial hopes to sort some of that out. Most people know LAMP: Linux, Apache, MySQL, and PHP. We will setup LAPR: Linux, Apache, PostgreSQL, and Ruby. Setting up a LAPR server is very similar to setting up a LAMP server. The only wrinkle is getting Rails to talk to Apache. Thankfully, there is Passenger aka mod\_rails. Passenger is like mod\_php. It makes running Rails applications easy as pie. In order to run a Rails application through Apache, create a virtual host pointing the document root to the applications public directory and you’ll be riding on rails.

Capistrano is another part that people may not be familiar with. Capistrano is a Ruby gem designed to execute tasks on one or more remote machines. You’ll need SSH access to use Capistrano. Capistrano, affectionately known as Cap, automates the deploy process. We can use cap to take our code from some a repo and push it to the server, stop/start/restart the server, write custom tasks required by our application (think install required gems), or disable/enable a maintenance page. Using cap is not required but it sure beats using FTP to copy all the files around! Cap’s real power comes from the ability to write custom tasks in Ruby to manipulate the server. I’ve written a lot of applications that allow user file uploads. Then on the server side, some directory needs to be created with proper permissions for the uploads to succeed. It’s easy enough to write a cap task to create the directory and set the permissions. Then, if you ever change servers, you can simply run the cap task to setup the server again. There are many things you can do with Capistrano. You could even automate this entire tutorial to set up any number of machines at once!

Tutorial Sandbox

In order to complete this tutorial, you’ll need SSH + sudo access. If you don’t have a spare server sitting around, you can create one in VirtualBox. You can easily create a new VM and network it with your host system. I did this for the tutorial. When you start your virtual machine, make sure you use a bridged adapter so your VM gets an IP on the same subnet. I started with a fresh install without any customization. If you have access to a VPS like SliceHost, you can use these instructions as well.

Be sure to view the screencast before analyzing the code below.

Creating The Deployer

    $ sudo adduser -m deployer
    $ sudo passwd deployer
    $ sudo visudo deployer ALL=(ALL) NOPASSWD: ALL
    $ su deployer
    $ mkdir ~/.ssh
    $ touch ~/.ssh/authorized_keys2
    $ chmod -R 0700 ~/.ssh
    # copy your public key and paste it into the authorized_keys2 file
    $ service sshd start

Setting Up Postgres

    $ sudo yum groupinstall "PostgreSQL Database"
    $ sudo service postgresql initdb
    $ sudo service postgresql start
    $ su - postgres
    $ psql -d template1
    $ alter user postgres with password 'yourpostgresuserpassword';
    $ \q
    # Replace ident in /var/usr/lib/pgsql/data/pg_hba.conf with md5
    $ passwd postgres
    # set extra security in /etc/phpPgAdmin/config.inc.php to false
    # add 'Allow from YOUR_IP_HERE' to vhost in /etc/httpd/conf.d/phpPgAdmin.conf
    # enable http in the firewall
    $ sudo yum install httpd
    $ sudo service httpd start
    $ sudo service postgresql restart

Configuring Ruby, RubyGems, and Passenger

    $ sudo yum groupinstall Ruby
    $ sudo yum install rubygems
    $ sudo gem install gemcutter
    $ sudo yum install postgresql-devel
    $ sudo gem install pg
    $ sudo gem install passenger
    $ yum install gcc-c++ httpd-devel apr-devel
    $ sudo passenger-install-apache2-module
    # create this file /etc/http/conf.d/passenger.conf with these contents:
      LoadModule passenger_module     /usr/lib/ruby/gems/1.8/gems/passenger-2.2.9/ext/apache2/mod_passenger.so
      PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.9
      PassengerRuby /usr/bin/ruby

    $ sudo setenforce 0
    $ sudo service httpd restart

Creating the Deployer Folder

    $ sudo mkdir /var/www/html/apps
    $ sudo chown deployer:apache /var/www/html/apps
    $ sudo yum install git
    # at this point, create your databases in phpPgAdmin
 

Configuring Apache

    # echo "Include vhost.d/*.vhost" >> /etc/httpd/conf/httpd.conf
    $ sudo mkdir /etc/httpd/vhost.d
    $ sudo touch /etc/httpd/vhost.d/nettuts-demo.vhost
    # update that files conttents to:
      
          ServerName www.nettuts-demo.com
          DocumentRoot /var/www/html/apps/nettuts-demo/current/public
          
            Options FollowSymLinks
              Allow from all
              Options -MultiViews
          

          RewriteEngine On
          RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
          RewriteCond %{SCRIPT_FILENAME} !maintenance.html
          RewriteRule $ /system/maintenance.html [R=302,L]
      

Complete Cap File

    set :application, "nettuts-demo"
    set :repository,  "git://github.com/Adman65/Nettuts-Capistrano-Deployments.git"

    set :user, :deployer

    set :deploy_to, "/var/www/html/apps/#{application}"

    set :use_sudo, false

    set :scm, :git

    role :web, "192.168.1.112"                          # Your HTTP server, Apache/etc
    role :app, "192.168.1.112"                          # This may be the same as your `Web` server
    role :db,  "192.168.1.112", :primary => true # This is where Rails migrations will run
    role :db,  "192.168.1.112"

    default_run_options[:pty] = true

    namespace :deploy do
       task :start do ; end
       task :stop do ; end
       task :restart, :roles => :app, :except => { :no_release => true } do
         run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
       end

       desc "Installs required gems"
       task :gems, :roles => :app do
         run "cd #{current_path} && sudo rake gems:install RAILS_ENV=production"
       end
       after "deploy:setup", "deploy:gems"   

       before "deploy", "deploy:web:disable"
       after "deploy", "deploy:web:enable"
    end