Difference between revisions of "Workshop - week 03"
| Line 1: | Line 1: | ||
[[Main Page]] >> [[Web Frameworks]] >> [[Web Frameworks - Workbook]] >> Workshop - week 03 | [[Main Page]] >> [[Web Frameworks]] >> [[Web Frameworks - Workbook]] >> Workshop - week 03 | ||
| − | === | + | ===Creating the Layout=== |
We can think of the [http://framework.zend.com/docs/quickstart/create-a-layout 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. | We can think of the [http://framework.zend.com/docs/quickstart/create-a-layout 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. | ||
| Line 106: | Line 106: | ||
| − | === | + | ===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. | 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 [http://framework.zend.com/docs/quickstart/create-a-configuration-and-registry 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. [http://framework.zend.com/docs/quickstart/create-a-configuration-and-registry 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. | A more modern take on the concept is to have a [http://framework.zend.com/docs/quickstart/create-a-configuration-and-registry 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. [http://framework.zend.com/docs/quickstart/create-a-configuration-and-registry 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. | ||
| + | |||
| + | ===References=== | ||
| + | |||
| + | All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved. | ||
| + | |||
| + | http://framework.zend.com/docs/quickstart/ | ||
| + | |||
| + | http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/ | ||
Revision as of 10:22, 28 January 2009
Main Page >> Web Frameworks >> Web Frameworks - Workbook >> Workshop - week 03
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.
You may have noticed that the view scripts in the previous sections were HTML fragments- not complete pages. This is by design; we want our actions to return content only related to the action itself, not the application as a whole.
Now we must compose that generated content into a full HTML page. We'd also like to have a consistent look and feel for the application. We will use a global site layout to accomplish both of these tasks.
There are two design patterns that Zend Framework uses to implement layouts: Two Step View and Composite View. Two Step View is usually associated with the Transform View pattern; the basic idea is that your application view creates a representation that is then injected into the master view for final transformation. The Composite View pattern deals with a view made of one or more atomic, application views.
In Zend Framework, Zend_Layout combines the ideas behind these patterns. Instead of each action view script needing to include site-wide artifacts, they can simply focus on their own responsibilities.
Occasionally, however, you may need application-specific information in your site-wide view script. Fortunately, Zend Framework provides a variety of view placeholders to allow you to provide such information from your action view scripts.
To get started using Zend_Layout, first we need to make some modifications to our bootstrap.php file:
<source lang="php"> // application/bootstrap.php // // Add the following code prior to the comment marked "Step 5" in // application/bootstrap.php. // // LAYOUT SETUP - Setup the layout component // The Zend_Layout component implements a composite (or two-step-view) pattern // With this call we are telling the component where to find the layouts scripts. Zend_Layout::startMvc(APPLICATION_PATH . '/layouts/scripts');
// VIEW SETUP - Initialize properties of the view object // The Zend_View component is used for rendering views. Here, we grab a "global" // view instance from the layout object, and specify the doctype we wish to // use. In this case, XHTML1 Strict. $view = Zend_Layout::getMvcInstance()->getView(); $view->doctype('XHTML1_STRICT');
// CLEANUP - remove items from global scope // This will clear all our local boostrap variables from the global scope of // this script (and any scripts that called bootstrap). This will enforce // object retrieval through the applications's registry. unset($view); </source>
Calling startMvc() registers a plugin with the front controller, allowing layouts to work seamlessly and without further interaction in most cases. An action helper is registered, as is a view helper, in case you do need to interact with the layout object.
Note the call to the doctype() view helper; this is one of the placeholders mentioned above. By setting this in the bootstrap, we can assure that other doctype-aware view helpers know the selected doctype.
Now that we've initialized Zend_Layout, let's create our site-wide layout:
<source lang="php"> <? /* application/layouts/scripts/layout.phtml
This line outputs the doctype we set in the bootstrap */ ?>
<?= $this->doctype() ?> <html xmlns="http://www.w3.org/1999/xhtml"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Zend Framework Quickstart Application</title>
<?= $this->headLink()->appendStylesheet('/css/global.css') ?>
</head> <body>
ZF Quickstart Application
<?= $this->layout()->content ?>
</body>
</html>
</source>
We grab our application content using the layout() view helper, and accessing the "content" key. You may render to other response segments if you wish to, but in most cases, this is all that's necessary.
Note also the use of the headLink() placeholder. This is an easy way to generate the HTML for <link> elements, as well as to keep track of them throughout your application. If you need to add additional CSS sheets to support a single action, you can do so, and be assured it will be present in the final rendered page.
Checkpoint
Now go to http://mi-linux.wlv.ac.uk/~YourStudentNumber/QuickStart/public ; and check out the source. You should see your xhtml header, head, title, and body sections.
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.
References
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved.
