Difference between revisions of "Workshop - week 01"

From mi-linux
Jump to navigationJump to search
m (Made the link a little nicer.)
 
(31 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.
  
−
<pre>
+
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();
 
−
?>
 
−
</pre>
 
−
Browse to the page using your web broswer, 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>
 
<pre>
Line 33: Line 43:
 
RewriteCond %{REQUEST_FILENAME} -d
 
RewriteCond %{REQUEST_FILENAME} -d
 
RewriteRule ^.*$ - [NC,L]
 
RewriteRule ^.*$ - [NC,L]
−
RewriteRule ^.*$ /index.php [NC,L]
+
RewriteRule ^.*$ /~<YourStudentNumber>/QuickStart/public/index.php [NC,L]
 
</pre>
 
</pre>
−
Would become:
+
 
 +
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:
 
<pre>
 
<pre>
−
# public/.htaccess
+
<?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() . '&lt;/pre></div>';
 +
    }
 +
    echo '</center></body></html>';
 +
    exit(1);
 +
}
 +
 
  
−
RewriteEngine On
+
// Step 4: DISPATCH:  Dispatch the request using the front controller.
−
RewriteCond %{REQUEST_FILENAME} -s [OR]
+
// The front controller is a singleton, and should be setup by now. We
−
RewriteCond %{REQUEST_FILENAME} -l [OR]
+
// will grab an instance and call dispatch() on it, which dispatches the
−
RewriteCond %{REQUEST_FILENAME} -d
+
// current request.
−
RewriteRule ^.*$ - [NC,L]
+
Zend_Controller_Front::getInstance()->dispatch();
−
RewriteRule ^.*$ /~<YourStudentNumber>/QucikStart/public/index.php [NC,L]
 
 
</pre>
 
</pre>
  
−
===3. Bootstrap File===
 
  
−
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.
 
  
−
Here there's a second mistake that we need to fix:
+
*'''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)
  
 
<pre>
 
<pre>
−
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
+
<?php
−
</pre>
+
// application/bootstrap.php
−
Would become:
+
//
−
<pre>
+
// 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->setControllerDirectory(APPLICATION_PATH . '/controllers');
 
$frontController->setBaseUrl('/~<YourStudentNumber>/QuickStart/public');
 
$frontController->setBaseUrl('/~<YourStudentNumber>/QuickStart/public');
 
$frontController->setParam('useDefaultControllerAlways', true);
 
$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);
 
</pre>
 
</pre>
  
−
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.
+
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.
 +
 
  
−
===Setting Up Our Default Controller and View===
+
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.
  
−
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.
+
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.
  
−
===Error Controller and 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.
  
−
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].
+
==References==
  
−
===Creating the Layout===
+
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved.
  
−
We can think of the [http://framework.zend.com/docs/quickstart/create-a-layout layout page] as a template that defines a consistant 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.
+
http://framework.zend.com/docs/quickstart/
  
−
===Configuration and Registry===
+
http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/
  
−
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 accessable by anonymous users.
+
== Ready to move on? ==
  
−
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. [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.
+
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/

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"