Sorry for the delay, but there is a lot to cover in these posts. I actually started a couple of times. Hopefully we can take this a small piece at a time going forward.
Maugrim_The_Reaper wrote:Should we setup Subversion somewhere to track this code? Eventually it's be easier to just throw anyone reading a link to grab what's added (after discussion here of course).
Probably.
Maugrim_The_Reaper wrote:Just to note to everyone else reading the AppRequest and AppResponse don't exist yet - don't throw yourself off the deep end if you run this

.
I changed my code to get rid of those.
I want to comment on your code in sections because it brings up many of the initial questions in this discussion:
Code: Select all
<?php
// Development settings only!!!
ini_set('display_errors', 1);
error_reporting(E_ALL|E_STRICT);
By putting these settings first they cannot use config setting to set error reporting -- such as on for development site but off for the live site. Should they set after config is defined?
Code: Select all
/**
* Set the /application path. This can either be the suggested
* option of a path below the webroot, or a relative path from
* the webroot (if distributing online).
*/
// $applicationPath = './application'; // if "/application" is in webroot
$applicationPath = '/path/to/application/directory';
Again, because this is before the configuration information a separate variable is used. That also means that the path cannot be changed by the config.
Code: Select all
// Basic setup (adjust timezone as needed)
date_default_timezone_set('America/Los_Angeles');
I have started to see date_default_timezone_set() in many demos. What are the pros/cons of having this setting explicit? Is it required or a php.ini setting?
Code: Select all
set_include_path(
'.' . PATH_SEPARATOR
. $applicationPath . '/user/models' . PATH_SEPARATOR
. $applicationPath . '/library/Zend/Incubator' . PATH_SEPARATOR
. $applicationPath . '/library/Zend/Core' . PATH_SEPARATOR
. get_include_path()
);
Two questions. First is whether the search path should just go to "/application" and then when you want a model you do "models/MyModel.php" or for misc code you do "inc/MyCode.php". Second is whether we should have have this Incubator/Core stuff still? Will it be necessary to stay current or is it just an artifact of the 0.1 - 0.9 process?
I think the path setting is important because it defines conventions within the program code. So it would be good to thing about the ramifications of different settings. I also leads to the question of whether to use _autoload()?
Code: Select all
// Load configuration
require 'Zend/Config/Ini.php';
$Config = new Zend_Config_Ini($applicationPath . '/config/config.ini', 'general');
As I discussed above, perhaps some configuration settings should be done sooner so they can be used in some of the above cases in this file. Also, have you looked into the differences between using a text config file (INI, XML, YAML) as opposed to using a PHP file containing an array of values? An array would also allow its values to be used here before the config object was created.
Code: Select all
// Setup the Registry
require 'Zend/Registry.php';
$Registry = Zend_Registry::getInstance();
$Registry->set('Config', $Config);
We need to set some standards for what the text strings for common objects in the registry are.
Code: Select all
// Detect Base URL from sanitised PHP_SELF Server variable
$_SERVER['PHP_SELF'] = substr($_SERVER['PHP_SELF'], 0, strlen($_SERVER['PHP_SELF']) - @strlen($_SERVER['PATH_INFO']));
$baseUrl = substr($_SERVER['PHP_SELF'], 0, -9); // strips the ending "index.php"
Is this needed or should this be either hard coded or come from the config data? I don't currently do this kind of processing in index.php because it is a set-once-and-it-works value.
Code: Select all
// Get a Front Controller instance
require 'Zend/Controller/Front.php';
$Front = Zend_Controller_Front::getInstance();
// Setup the Front Controller with any application specific settings
$Front->throwExceptions(true)
->setBaseUrl($baseUrl)
->setControllerDirectory($applicationPath . '/controllers')
->setParam('Registry', $Registry)
->returnResponse(true);
You use the fluent syntax as opposed to standard method calls. What do people prefer? Is there a performance difference?
Code: Select all
// Dispatch the Request and get the Response!
$Response = $Front->dispatch();
// Echo the Response
echo $Response;
There are some more details about the response that we will probably need to get into later. A big one is whether there is an outer View object that is defined here in index.php?
Maugrim_The_Reaper wrote:Here's the .htaccess:
Code: Select all
RewriteEngine on
RewriteCond %{REQUEST_URI} !/public.*
RewriteRule .* index.php
Slightly different to yours. Maps everything onto index.php as path information, but excludes a specific directory instead for files which may be directly referenced. I find this a bit better than the suggested Zend Framework Manual .htaccess which specifies file extensions one by one.
I am not sure which way is better. I think I would prefer to keep the rules as simple as possible and add additional .htaccess files (with "RewriteEngine off" in it) where you don't want rewriting. The "/public" seems nonstandard to me.
Maugrim_The_Reaper wrote:My own suggested filesystem layout is a bit different. Still retains the important distinction between files below, and above the webroot. Otherwise it's the suggested Zend Framework layout from the Developer Wiki only with all public files sourced from a single "public" directory (to limit Rewrite Conditions in .htaccess). "webroot" is simply the "/demo/petshop" path in the document root of the webserver. Removed the View subdirs until needed. Haven't defined /library/Zend subdirectories on the assumption the framework download/updating will be managed via subversion externals (will post a quickie on that later).
Code: Select all
/application
/config
/library
/Zend
/user
/controllers
/models
/views
/webroot
/public
/images
/styles
/javascript
.htaccess
index.php
Thoughts and comments on the changes?
Again, I am not sure I like the non-standard "/webroot/public" and /application/user" directories. A separate directory for config files does make sense. I am also wondering about the whole "/library" path. Things could almost be simplified by just putting everything into "/application". It is not as though it will get that that cluttered. An "/Zend" could be a symbolic link. So maybe something like:
Code: Select all
/application
/config
/controllers
/models
/views
/filters
/helpers
/scripts
/Zend
/document_root
/images
/scripts
/styles
.htaccess
index.php