Difference between revisions of "Workshop - week 01"
m (Made the link a little nicer.) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Main Page]] >> [[Web Frameworks]] >> [[Web Frameworks - Workbook]] >> Workshop - week 01 | + | [[Main Page]] >> [[CP2132|Web Frameworks]] >> [[Web Frameworks - Workbook|Workbook]] >> Workshop - week 01 |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Quick Start Zend Framework== | ==Quick Start Zend Framework== | ||
| Line 102: | Line 90: | ||
echo '<br /><br />' . $exception->getMessage() . '<br />' | echo '<br /><br />' . $exception->getMessage() . '<br />' | ||
. '<div align="left">Stack Trace:' | . '<div align="left">Stack Trace:' | ||
| − | . '<pre>' . $exception->getTraceAsString() . ' | + | . '<pre>' . $exception->getTraceAsString() . '</pre></div>'; |
} | } | ||
echo '</center></body></html>'; | echo '</center></body></html>'; | ||
| Line 174: | Line 162: | ||
The action controllers under the directory mentioned in step 3 of bootstrap.php above comprise the part of your application that will process the user request next. Action controllers, also called page controllers, represent the 'controller' part of the model-view-controller pattern. There is obviously a lot that happens after the dispatch() method takes over and before it hands over control to your action controller, but you don't necessarily need to know the details to write full featured applications. See the Reference Guide for details on how requests are dispatched. | The action controllers under the directory mentioned in step 3 of bootstrap.php above comprise the part of your application that will process the user request next. Action controllers, also called page controllers, represent the 'controller' part of the model-view-controller pattern. There is obviously a lot that happens after the dispatch() method takes over and before it hands over control to your action controller, but you don't necessarily need to know the details to write full featured applications. See the Reference Guide for details on how requests are dispatched. | ||
| − | + | ==References== | |
| − | |||
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved. | All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved. | ||
| Line 182: | Line 169: | ||
http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/ | http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/ | ||
| + | |||
| + | == Ready to move on? == | ||
| + | |||
| + | When you're happy you understand what you've done here, take a look at the [[Workshop_-_week_02|Week 2 Workshop]] | ||
Latest revision as of 18:59, 21 July 2009
Main Page >> Web Frameworks >> Workbook >> Workshop - week 01
Quick Start Zend Framework
We are going to be following the Zend Framework Quickstart tutorial to ensure we can get Zend to work properly from our University area.
Let's first create a basic MVC project structure for our application under the directory QuickStart. This needs to be set up within your public_html folder so that it is displayed publically on the Internet.
Create the folder structure on your local machine initially, in your U:\ drive, so that you can put all the files in the correct location, ready to FTP across. Be very careful about getting the capitilisation right - linux is case-sensitive!
QuickStart\
application\
config\
controllers\
forms\
layouts\
scripts\
models\
DbTable\
views\
scripts\
data\
db\
public\
(So we create QuickStart within public_html. Then inside QuickStart, we create application, data and public. Inside application, we create config, controllers, forms, layouts, models and views. Inside layouts we create scripts. Inside models we create DbTable. Inside views we create scripts and inside data we create db. This can be done via Shell, or via FTP access.)
Using either an FTP client (FileZilla, WS-FTP, etc), or using a Shell prompt through putty, set up the folder structure outlined above.
Setting Up .htaccess
Zend Framework's MVC implementation makes use of the Front Controller pattern. You must therefore rewrite all incoming requests (except those for static resources, which your application need not handle) to a single script that will initialize the FrontController and route the request. Create the file QuickStart/public/.htaccess with the following contents:
# public/.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /~<YourStudentNumber>/QuickStart/public/index.php [NC,L]
This set of rewrite rules specify that if the file exists under the document root directory, it should simply be served as a static resource. Otherwise, the request is for dynamic content and should be rewritten to our index.php script. Since all requests for non-static content will be rewritten to it, the index.php script serves as the entry point to our application.
Bootstrap File
Create a Bootstrap File
Let's take a quick look at that index.php file now. Create a new file at public/index.php with the following:
<?php
// public/index.php
//
// Step 1: APPLICATION_PATH is a constant pointing to our
// application/subdirectory. We use this to add our "library" directory
// to the include_path, so that PHP can find our Zend Framework classes.
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application/'));
set_include_path(
APPLICATION_PATH . '/../library'
. PATH_SEPARATOR . get_include_path()
);
// Step 2: AUTOLOADER - Set up autoloading.
// This is a nifty trick that allows ZF to load classes automatically so
// that you don't have to litter your code with 'include' or 'require'
// statements.
require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();
// Step 3: REQUIRE APPLICATION BOOTSTRAP: Perform application-specific setup
// This allows you to setup the MVC environment to utilize. Later you
// can re-use this file for testing your applications.
// The try-catch block below demonstrates how to handle bootstrap
// exceptions. In this application, if defined a different
// APPLICATION_ENVIRONMENT other than 'production', we will output the
// exception and stack trace to the screen to aid in fixing the issue
try {
require '../application/bootstrap.php';
} catch (Exception $exception) {
echo '<html><body><center>'
. 'An exception occured while bootstrapping the application.';
if (defined('APPLICATION_ENVIRONMENT')
&& APPLICATION_ENVIRONMENT != 'production'
) {
echo '<br /><br />' . $exception->getMessage() . '<br />'
. '<div align="left">Stack Trace:'
. '<pre>' . $exception->getTraceAsString() . '</pre></div>';
}
echo '</center></body></html>';
exit(1);
}
// Step 4: DISPATCH: Dispatch the request using the front controller.
// The front controller is a singleton, and should be setup by now. We
// will grab an instance and call dispatch() on it, which dispatches the
// current request.
Zend_Controller_Front::getInstance()->dispatch();
- HINT: There is no need to worry about missing php end-tags - they are intentionally omitted in order to avoid any unintentional whitespace output.
For security reasons, it is advisable to keep your application's scripts in a directory that your web server does not make publicly accessible. In this case, index.php quickly hands over control to the bootstrap.php file, which resides in the more secure application directory. Some logic is kept in the index.php script to make controller testing simpler. More on this later.
Now we need to create our bootstrap.php file, so called because it 'bootstraps' the application on each user request. Create the application/bootstrap.php file with the following contents:
(Create this file at application/bootstrap.php)
<?php
// application/bootstrap.php
//
// Step 1: APPLICATION CONSTANTS - Set the constants to use in this application.
// These constants are accessible throughout the application, even in ini
// files. We optionally set APPLICATION_PATH here in case our entry point
// isn't index.php (e.g., if required from our test suite or a script).
defined('APPLICATION_PATH')
or define('APPLICATION_PATH', dirname(__FILE__));
defined('APPLICATION_ENVIRONMENT')
or define('APPLICATION_ENVIRONMENT', 'development');
// Step 2: FRONT CONTROLLER - Get the front controller.
// The Zend_Front_Controller class implements the Singleton pattern, which is a
// design pattern used to ensure there is only one instance of
// Zend_Front_Controller created on each request.
$frontController = Zend_Controller_Front::getInstance();
// Step 3: CONTROLLER DIRECTORY SETUP - Point the front controller to your action
// controller directory.
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
$frontController->setBaseUrl('/~<YourStudentNumber>/QuickStart/public');
$frontController->setParam('useDefaultControllerAlways', true);
// Step 4: APPLICATION ENVIRONMENT - Set the current environment.
// Set a variable in the front controller indicating the current environment --
// commonly one of development, staging, testing, production, but wholly
// dependent on your organization's and/or site's needs.
$frontController->setParam('env', APPLICATION_ENVIRONMENT);
// Step 5: 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($frontController);
We have changed some of the code in step 3 from what the tutorial states. We're saying "This is not using the root folder of the server; instead, we are using a sub-directory." As our accounts on mi-linux are set up as sub-directories, this is important. The final line of code is telling the front controller to use the default controller (Our IndexController) if a Controller we haven't got is requested. This means that if a user goes to a page we haven't set up, ( http://mi-linux.wlv.ac.uk/~in9301/QuickStart/public/thisPageDoesntExistAndWillRedirectToIndex ) they will see the index view instead.
At this point you should start to see your application taking shape. The bootstrap.php and index.php scripts set up the application environment. These scripts typically should not contain business logic for your application, however.
You may ask why the call to dispatch() is made outside the bootstrap.php file. The rationale is for later down the line when you start functional testing your applications; with the above strategy, you can re-use your bootstrap.php script to setup your application environment when testing. This topic will be covered in a later tutorial.
The action controllers under the directory mentioned in step 3 of bootstrap.php above comprise the part of your application that will process the user request next. Action controllers, also called page controllers, represent the 'controller' part of the model-view-controller pattern. There is obviously a lot that happens after the dispatch() method takes over and before it hands over control to your action controller, but you don't necessarily need to know the details to write full featured applications. See the Reference Guide for details on how requests are dispatched.
References
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved.
http://framework.zend.com/docs/quickstart/
Ready to move on?
When you're happy you understand what you've done here, take a look at the Week 2 Workshop
