epwzf20

ErrorLog "logs/dev.gamenomad.com-error.log" CustomLog "logs/dev.gamenomad.com-access.log" common

</VirtualHost>

The ServerAdmin setting is irrelevant because Windows machines are not by default configured to send e-mail. The DocumentRoot should define the absolute path pointing to the Zend Framework project's public directory (more on this in a bit). The ServerName and ServerAlias settings should identify the name of the website as you would like to access it locally. Finally, the ErrorLog and CustomLog settings can optionally be used to log local traffic.

Save the httpd-vhosts.conf file and restart Apache. Finally, open the hosts file, which on Windows XP and Windows 7 is located in the directory C:\WINDOWS\system32\drivers\etc. Presuming you've never modified this file, the top of the file will contain some comments followed by this line:

127.0.0.1 localhost

Add the following line directly below the above line:

127.0.0.1 dev.gamenomad.com

Save this file and when you navigate to http://dev.gamenomad.com, your machine will attempt to resolve this domain locally. If Apache is running and you access this URL via your browser, Apache will look to the virtual host file and server the domain's associated website.

Configuring a Virtual Host on Ubuntu

Ubuntu deviates from Apache's default approach to virtual host management in a very practical way, defining each virtual host within a separate file which is stored in the directory /etc/apache2/ sites-available/. For instance, a partial listing of my development machine's sites-available directory looks like this:

dev.gamenomad.com

dev.wjgilmore.com

All of these files include a VirtualHost container which defines the website's root directory and default behaviors as pertinent to Apache's operation. This is a fairly boilerplate virtual host definition, insomuch that when I want to create a new virtual host I just copy one of the files found in sitesavailable and rename it accordingly. What's important is that you notice how the DocumentRoot and Directory definitions point to the website's public directory, because that's where the front controller resides. For instance, the dev.gamenomad.com file looks like this:

Figure 2.1. A Zend Framework Project's Home Page

If this page doesn't appear, double-check both the changes you made to Apache's configuration file and your system's hosts file to make sure there aren't any spelling mistakes, and that the directory you reference in the virtual host is indeed the correct one.

The Project Structure

A Zend Framework project structure consists of quite a few directories and files, each of which plays an important role in the website's operation. Taking some time to understand their specific roles is going to help you to swiftly navigate among and modify these files as your site begins to take shape. Open a terminal window and list the contents of the newly created project's home directory. There you'll find five directories and one file, each of which is introduced next:

• application: The application directory contains the bulk of your website's domain-specific features, including the actions, configuration data, controllers, models, and views. Additionally, this directory contains a file named Bootstrap.php, which is responsible for initializing data and other resources specific to your website. I'll return to this file throughout the book as needed.

• docs: The docs directory is intended to store your website's developer documentation, including notably documentation generated using an automated solution such as PHPDoc.

the .zfproject.xml manifest introduced in the previous section to be the sole determinant in regards to the current project state. Therefore if you manually create a project component such as a controller and then later try to add an action to the controller using zf, you will be greeted with a warning stating that the controller does not exist, because there is no record of it existing as determined by the .zfproject.xml file.

Creating Controllers

When a new project is generated, zf will also create the Index and Error controllers, so you can go about modifying the Index controller right away. As you expand the site, you'll logically want to create additional controllers. For instance, we might create a controller named About which will visitors a bit more about your organization. To do this, use the create controller command:

%>zf create controller About

Executing this command will result in the creation of the About controller containing one action named IndexAction, a corresponding index view, and an About controller test file. The project profile (.zfproject.xml) is also updated to reflect the latest changes to the project.

The generated AboutController.php (located in application/controllers/) contains the following contents:

<?php

class AboutController extends Zend_Controller_Action

{

public function init()

{

/* Initialize action controller here */

}

public function indexAction()

{

// action body

}

}

First and foremost, note that the controller extends the Zend_Controller_Action class. In doing so, the controller class will be endowed with the special characteristics and behaviors necessary to function within the Zend Framework environment. One such special characteristic is the init()

method, located at the top of the class. This method will execute prior to the execution of any action found in the controller, meaning you can use init() to initialize parameters or execute tasks which are relevant to more than one action.

You'll also find a method named IndexAction. When generating a new controller this action and its corresponding view (named index.phtml) will also be created. The index action is special because the Zend Framework will automatically refer to it when you access the controller via the browser with no corresponding action. For instance, if you were to access http://dev.gamenomad.com/about, the About controller's index action will automatically execute. If you want zf to skip creating an index view, pass a second parameter of 0 to the create controller command, like so:

%>zf create controller About 0

Navigate to http://dev.gamenomad.com/about/ and you'll see that the About controller has indeed been created, along with an corresponding view which contains some placeholder text. Consider opening index.phtml (located in application/views/scripts/about/) and replacing the placeholder text with some background information about your website. Remember that in your view you can use HTML, so format the information however you please.

Creating Actions

You can add an action to an existing controller using the create action command. For instance, to add an action named contact to the About controller, use the following command:

%>zf create action contact About

The default behavior of this command is to also create the corresponding contact.phtml view. To override this default, pass a third parameter of 0 like so:

%>zf create action contact About 0

Creating Views

You can use the create view command to create new views. At the time of writing, this command works a bit differently than the others, prompting you for the controller and action:

%>zf create view

Please provide a value for $controllerName zf> About

Please provide a value for $actionNameOrSimpleName zf> contact

Updating project profile '/var/www/dev.gamenomad.com/.zfproject.xml'

Keep in mind this command only creates the view. If you want to create an action and a corresponding view, use the create action command.

Passing Data to the View

Recall that the view's primary purpose is to display data. This data will typically be retrieved from the model by way of the corresponding controller action. To pass data from the action to its corresponding view you'll assign the data to the $this->view object from within the action. For instance, suppose you wanted to associate a specific page title with the About controller's index action. The relevant part of that action might look like this:

public function indexAction()

{

$this->view->pageTitle = "About GameNomad";

}

With this variable defined, you'll be able to reference it within your view like this:

<title><?= $this->pageTitle; ?></title>

Retrieving GET and POST Parameters

The dynamic nature of most websites is dependent upon the ability to persist data across requests. For instance a video game console name such as ps3 might be passed as part of the URL (e.g. http:// dev.gamenomad.com/games/console/ps3). The requested page could use this parameter to consult a database and retrieve a list of video games associated with that console. If a visitor wanted to subscribe to your newsletter, then he might pass his e-mail address through an HTML form, which would then be retrieved and processed by the destination page.

Data is passed from one page to the next using one of two methods, either via the URL (known as the GET method) or as part of the message body (known as the POST method). I'll spare you the detailed technical explanation, however you should understand that the POST method should always be used for requests which add or change the world's "state", so to speak. For instance, submitting a user registration form will introduce new data into the world, meaning the proper method to use is POST. On the contrary, the GET method should be used in conjunction with requests which would have no detrimental effect if executed multiple times, such as a web search effected through a search engine. Forms submitted using the GET method will result in the data being passed by way of the URL. For instance, if you head on over to Amazon.com and search for a book, you'll see the search keywords passed along on the URL.

The distinction is important because forms are often used to perform important tasks such as processing a credit card. Browser developers presume such forms will adhere to the specifications and be submitted using the POST method, thereby warning the user if he attempts to reload the page in order to prevent the action from being performed anew (in this case, charging the credit card a second time). If GET was mistakenly used for this purpose, the browser would logically not warn the user, allowing the page to be reloaded and the credit card potentially charged again (I say potentially because the developer may have built additional safeguards into the application to prevent such accidents). Given the important distinction between these two methods, keep the following in mind when building web forms:

•Use GET when the request results in an action being taken that no matter how many times it's submitted anew, will not result in a state-changing event. For instance, searching a database repeatedly will not affect the database's contents, making a search form a prime candidate for the GET method.

•Use POST when the request results in a state-changing event, such as a comment being posted to a blog, a credit card being charged, or a new user being registered.

In the sections that follow I'll show you how to retrieve data submitted using the GET and POST methods. Understanding how this is accomplished will be pivotal in terms of your ability to build dynamic websites.

Retrieving GET Parameters

The Zend Framework's default routing behavior follows a simple and intuitive pattern in which the request's associated controller and action are specified within the URL. For instance, consider the following URL:

http://dev.gamenomad.com/games/list/console/ps3

The framework's default behavior in this instance would be to execute the Games controller's list action. Further, a GET parameter identified by the name console has been passed and is assigned the value ps3. To retrieve this parameter from within the list action you'll use a method named getParam() which is associated with a globally available _request object:

$console = $this->_request->getParam('console');

If the list action was capable of paging output (see Chapter 6 for more information about pagination), you might pass the current page number along as part of the URL:

http://dev.gamenomad.com/games/list/console/ps3/page/4

This URL may also be accompanied by one or more parameters which the action may accept as input. To recap this behavior, consider the following URL:

http://dev.gamenomad.com/games/view/asin/B000TG530M/

When this URL is requested, the Zend Framework's default behavior is to route the request to the Games controller's view action, passing along a GET parameter named asin which has been assigned the value B000TG530M. But what if you wanted the URL to look like this:

http://dev.gamenomad.com/games/B000TG530M

Tip

The parameter asin stands for Amazon Standard Identification Number, which uniquely identifies products stored in the Amazon.com product database. See Chapter 10 for more information about how GameNomad retrieves video game data from Amazon.com.

It's possible to allow this URL to continue referring to the Games controller's view action by creating a custom route. You can use the Zend Framework's custom routing feature to not only override the framework's default behavior, but also to set default parameter values and even use regular expressions which can route requests to a specific controller action whenever the defined expression pattern is matched.

To create a custom route open the Bootstrap.php file, located in your project's application directory. You might recall that earlier in the chapter I mentioned the Bootstrap.php file was useful for initializing data and other resources specific to your website, including custom routes. The Bootstrap.php file's behavior is a tad unusual, as any method embedded within the Bootstrap class found in this file will automatically execute with each invocation of the framework (with every request). Further, these method names must be prefixed with _init, otherwise they will be ignored. Therefore in order for the custom routes to work, you'll need to embed them within an appropriately named method named _initRoutes, for instance.

Let's create a custom route which makes it very easy for users to login by navigating to http:// dev.gamenomad.com/login. Doing so will actually result in the execution of the Account controller's login action (which we'll talk about in detail in Chapter 8). The code is presented next, followed by an explanation:

01 public function _initRoutes()

02 {

03 $frontController = Zend_Controller_Front::getInstance();

04 $router = $frontController->getRouter();

05

06 $route = new Zend_Controller_Router_Route_Static (