Difference between revisions of "Workshop - week 01"

From mi-linux
Jump to navigationJump to search
m (Made the link a little nicer.)
 
(23 intermediate revisions by 6 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
  
−
===1. PHP Info===
+
==Quick Start Zend Framework==
  
−
One thing that is not mentioned in the Quick Start, which is often a good idea to do when you begin working on a new PHP server for the first time is uploading a [http://uk2.php.net/phpinfo PHP Info] test file.
+
We are going to be following the Zend Framework Quickstart tutorial to ensure we can get Zend to work properly from our University area.
  
−
<source lang="php">
+
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.  
−
<?php
 
−
// Shows all information, defaults to INFO_ALL
 
−
phpinfo();
 
−
?>
 
−
</source>
 
−
Browse to the page using your web browser, and hopefully you should get a page outlining the various configurations on the server. If all appears well with the PHP info file, we can move on.
 
  
−
==Quick Start Zend Framework==
+
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!
  
−
We are going to be following the Zend Framework Quickstart tutorial to ensure we can get Zend to work properly from our University area.
+
<pre>
 +
QuickStart\
 +
  application\
 +
      config\
 +
      controllers\
 +
      forms\
 +
      layouts\
 +
          scripts\
 +
      models\
 +
          DbTable\
 +
      views\ 
 +
          scripts\
 +
  data\
 +
      db\
 +
  public\
 +
</pre>
  
−
Following how to [http://framework.zend.com/docs/quickstart/set-up-the-project-structure set up a project structure], we need to create a directory structure in our personal space.
+
(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 ([http://filezilla-project.org/download.php FileZilla], WS-FTP, etc), or using a Shell prompt through [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html putty], set up the folder structure [http://framework.zend.com/docs/quickstart/set-up-the-project-structure outlined here.]
+
Using either an FTP client ([http://filezilla-project.org/download.php FileZilla], WS-FTP, etc), or using a Shell prompt through [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html putty], set up the folder structure outlined above.
  
−
===2. Setting Up .htaccess===
+
===Setting Up .htaccess===
  
−
Following the instructions outlined [http://framework.zend.com/docs/quickstart/create-a-rewrite-rule here], set up the .htaccess file, and copy it to the QuickStart/public/ folder. There is a mistake on the page - you need to change this line from the tutorial.
+
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:
  
−
<pre>
 
−
# public/.htaccess
 
−
 
−
RewriteEngine On
 
−
RewriteCond %{REQUEST_FILENAME} -s [OR]
 
−
RewriteCond %{REQUEST_FILENAME} -l [OR]
 
−
RewriteCond %{REQUEST_FILENAME} -d
 
−
RewriteRule ^.*$ - [NC,L]
 
−
RewriteRule ^.*$ /index.php [NC,L]
 
−
</pre>
 
−
Would become:
 
 
<pre>
 
<pre>
 
# public/.htaccess
 
# public/.htaccess
Line 47: Line 46:
 
</pre>
 
</pre>
  
−
===3. Bootstrap File===
+
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.  
  
−
Set up QuickStart/public/index.php as outlined [http://framework.zend.com/docs/quickstart/create-a-bootstrap-file here]. Then set up application/bootstrap.php.
+
===Bootstrap File===
  
−
Here there's a second mistake that we need to fix:
+
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:
 
<pre>
 
<pre>
−
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
+
<?php
−
</pre>
+
// public/index.php
−
Would become:
+
//
−
<pre>
+
// Step 1: APPLICATION_PATH is a constant pointing to our
−
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
+
// application/subdirectory. We use this to add our "library" directory
−
$frontController->setBaseUrl('/~<YourStudentNumber>/QuickStart/public');
+
// to the include_path, so that PHP can find our Zend Framework classes.
−
$frontController->setParam('useDefaultControllerAlways', true);
+
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application/'));
−
</pre>
+
set_include_path(
 +
    APPLICATION_PATH . '/../library'  
 +
    . PATH_SEPARATOR . get_include_path()
 +
);
  
−
What we are changing here is 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.
+
// 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();
  
−
===Setting Up Our Default Controller and View===
+
// 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() . '&lt;/pre></div>';
 +
    }
 +
    echo '</center></body></html>';
 +
    exit(1);
 +
}
  
−
Next we need to set up our [http://framework.zend.com/docs/quickstart/create-an-action-controller-and-view default controller and view]. As we are using the Zend Framework defaults, the controller class only requires skeleton code.
 
  
−
===Error Controller and View===
+
// 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();
 +
</pre>
  
−
Because of the change we made by making all requests return the default view, essentially we remove the need for the ErrorHandler that is handling EXCEPTION_NO_CONTROLLER. However, it is good practice to set up the respective error handlers, and so we will continue to [http://framework.zend.com/docs/quickstart/create-an-error-controller-and-view follow the tutorial].
 
  
−
===4. 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.
+
*'''HINT''': ''There is no need to worry about missing php end-tags - they are intentionally omitted in order to avoid any unintentional whitespace output.''
  
−
===5. Configuration and Registry===
+
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.  
  
−
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.
+
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:
  
−
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.
+
(Create this file at application/bootstrap.php)
  
−
===6. Model and Database===
+
<pre>
 +
<?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__));
  
−
See [http://framework.zend.com/docs/quickstart/create-a-model-and-database-table here].
+
defined('APPLICATION_ENVIRONMENT')
 +
    or define('APPLICATION_ENVIRONMENT', 'development');
  
−
====Database====
+
// 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();
  
−
=====Database Connection=====
+
// Step 3: CONTROLLER DIRECTORY SETUP - Point the front controller to your action
−
 
+
// controller directory.
−
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.)
+
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
−
 
+
$frontController->setBaseUrl('/~<YourStudentNumber>/QuickStart/public');
−
We then need to modify the bootstrap.php file, to include the new connection details to the database we are about to create.
+
$frontController->setParam('useDefaultControllerAlways', true);
−
 
 
−
=====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:
+
// 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);
  
−
<pre>    protected function _getGuestbookForm()
+
// Step 5: CLEANUP - Remove items from global scope.
−
    {
+
// This will clear all our local boostrap variables from the global scope of
−
        require_once APPLICATION_PATH . '/forms/GuestBook.php';
+
// this script (and any scripts that called bootstrap).  This will enforce
−
        $form = new Form_GuestBook();
+
// object retrieval through the applications's registry.
−
        $form->setAction($this->_helper->url('sign'));
+
unset($frontController);
−
        return $form;
 
−
    }
 
 
</pre>
 
</pre>
  
−
Should become:
+
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.
  
−
<pre>
 
−
    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;
 
−
    }
 
−
</pre>
 
  
−
=====Guestbook Controller=====
+
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.
  
−
[http://framework.zend.com/docs/quickstart/create-a-form In our final steps], we need to create a form through which entries can be inserted.  
+
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.
−
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=====
+
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.
  
−
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.
+
==References==
−
 
  
−
===7. Form===
+
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved.
−
 
 
−
We now [http://framework.zend.com/docs/quickstart/create-a-form 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.
 
  
 +
http://framework.zend.com/docs/quickstart/
  
 +
http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/
  
 +
== Ready to move on? ==
  
−
===References===
+
When you're happy you understand what you've done here, take a look at the [[Workshop_-_week_02|Week 2 Workshop]]
−
 
 
−
http://framework.zend.com/docs/quickstart/
 
−
 
 
−
http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/
 

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/

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 Week 2 Workshop

Retrieved from "https://mi-linux.wlv.ac.uk/wiki/index.php?title=Workshop_-_week_01&oldid=4319"