Workshop - week 03

Main Page >> Web Frameworks >> Web Frameworks - Workbook >> Workshop - week 03

4. Creating the Layout

We can think of the layout page as a template that defines a consistent look and feel for all pages within the MVC application. The controllers provide views that fill in what is unique about a particular page. Combined together, they provide us with a complete HTML/XHTML page. As the tutorial suggests, this is the reason why the layout is a good place to set up headers and footers that we want to remain the same for all our pages.

5. Configuration and Registry

In older web programming methodologies, programmers would often create a file to be 'included' by all pages that needed access to database connections. This had many disadvantages, such as providing all the code for database connectivity often to every page, even when a database connection was not required for the page. There was also the security considerations of having a file with all the database connection details in a location where it may be accessible by anonymous users.

A more modern take on the concept is to have a registry / configuration file, and classes to provide access to the data. It works much like an .ini file for desktop applications - providing a place to store application-wide settings, such as database connection strings. It works much like a hashtable, where data can be retrieved by key name. We need to create our app.ini file, and modify the boostrap.php file to include a reference to the app.ini. In the case of our QuickStart application, we will then be able to access the database settings from any page we choose.

6. Model and Database

See here.

Database

Database Connection

Next, we need somewhere to store our data. We modify the app.ini file to include the database connection details (We are setting up a SQLite database - it is not a database you will necessarily be familiar with. Rather than having a database program running on a server, SQLite can have an entire database stored within a file - like using an XML file, but with all the benefits of SQL queries.)

We then need to modify the bootstrap.php file, to include the new connection details to the database we are about to create.

Database Schema

We then create two SQL script files - one that defines the structure of the database that we want to set up, and another with some initial test data to be inserted into the new database.

Setup Script

This PHP file will be run just once, and will create our database by executing the first script, and fill it with data as outlined by our second script. Once scripts/load.sqlite.php has been executed successfully, the file can be deleted - but don't do so until you have a fully working application, in case you need to execute the database setup again.

Pro Tip: Remember that the directories that the database is being set up within - data/db/ - need to have the correct permissions set. At this stage, CHMOD it to 777 (read, write and execute for all) to help get the application running.

Coding

Data Connector

Now we need a small class to define how our normal database queries (update, insert, delete) should be handled. In our system, we only require an insert method, as we'll be only allowing inserts into the guestbook. However, to follow best practice we include an update method, but set it so that it will throw an exception error if the update is called. Our insert method with automatically add the date and time of the insert to the database.

Set-up Model File

The model is what establishes business rules within our application. All methods relating to how our page does what it does should be defined here. We need to be able to retrive records from our database, so that the guestbook can display entries. It includes a function to return one entry, all entries - as well as a function that uses the insert we just set up to save new entries to the database.

We have one more line that needs changing in here:

    protected function _getGuestbookForm()
    {
        require_once APPLICATION_PATH . '/forms/GuestBook.php';
        $form = new Form_GuestBook();
        $form->setAction($this->_helper->url('sign'));
        return $form;
    }

Should become:

    protected function _getGuestbookForm()
    {
        require_once APPLICATION_PATH . '/forms/GuestBook.php';
        $form = new Form_GuestBook();
        $form->setAction($this->_request->getBaseUrl() . $this->_helper->url('sign'));
        return $form;
    }

Guestbook Controller

In our final steps, we need to create a form through which entries can be inserted. To tie all the functionality together we have just implemented, we need our guestbook controller. This will call functions in the data connector class we just completed, so that data to be saved can be passed to it, and retrieved records can be displayed through our view.

Guestbook View

And as we have our guestbook controller, we need a guestbook view. This will be used to display our guestbook records, as well as offering a link to set our guestbook action to sign, so that a record can be inserted.

7. Form

We now need a form; somewhere our users can actually insert their entry. We create a function to initialize the class, which includes all the controls needed for the form, such as the text boxes and the captcha. As can be seen, a captcha control exists within the Zend Framework - we simply state what kind we want, how many letters should be displayed, and what the timeout is before it becomes invalid.

We then modify our GuestbookController to include a sign action; providing users with a means of signing our guestbook.

And as we know by know - new code in the Controller giving us something new to process = new view, so we create a new view for our signing action.

And with the signing view complete, we should have a fully working GuestBook application. Load it up and test it out.