Difference between revisions of "Workshop - week 01"

From mi-linux
Jump to navigationJump to search
m (Made the link a little nicer.)
 
(30 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 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/'));
 +
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);
 +
}
 +
 
 +
 
 +
// 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>
 
</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.
 
  
−
===Setting Up Our Default Controller and View===
 
  
−
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.
+
*'''HINT''': ''There is no need to worry about missing php end-tags - they are intentionally omitted in order to avoid any unintentional whitespace output.''
  
−
===Error Controller and View===
+
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.
  
−
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].
+
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:
  
−
===Creating the Layout===
+
(Create this file at application/bootstrap.php)
  
−
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.
+
<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__));
  
−
===Configuration and Registry===
+
defined('APPLICATION_ENVIRONMENT')
 +
    or define('APPLICATION_ENVIRONMENT', 'development');
  
−
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.
+
// 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();
  
−
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.
+
// 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);
  
−
===Model and Database===
+
// 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);
  
−
See [http://framework.zend.com/docs/quickstart/create-a-model-and-database-table here].
+
// 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>
  
−
====Database====
+
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.
  
−
=====Database Connection=====
 
  
−
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.)
+
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.
  
−
We then need to modify the bootstrap.php file, to include the new connection details to the database we are about to create.
+
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.
  
−
=====Database Schema=====
+
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.
  
−
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.
+
==References==
  
−
=====Setup Script=====
+
All work relating to the QuickStart tutorial is © 2006 - 2009 by Zend Technologies Ltd. All rights reserved.
  
−
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.
+
http://framework.zend.com/docs/quickstart/
  
−
'''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.
+
http://www.johnmee.com/2008/11/zend-framework-quickstart-tutorial-deploy-to-a-subdirectory-instead-of-web-root/
  
 +
== Ready to move on? ==
  
−
=====Set-up Model File=====
+
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"