I'm less inclined to be rid of it - it seems perfectly logical that
Zend.php is the 'glue' for all other components within the framework,
so why not have it perform bootstrap-specific functionality:-
Zend::autoLoad([ $dirs ])
If called then loads a file with __autoload() that utilises
Zend::load to autofind classes. It would also set the current PHP
include path to the parent directory of the Zend.php file (as well as
any dirs referenced in the optional args).
Zend::load($file, [ $dirs ])
Deprecates loadClass/loadInterface - it's sole purpose is to include
files and check for the existence of the target class name. It simply
throws an exception upon failure without all the extra workarounds in
the isReadable function. If a file doesn't exist then PHP itself
should throw warnings/fatal errors and it is up to the application
itself to deal with runtime errors.
Zend::setPath($id, $path) / Zend::getPath($id)
Allows registering of absolute paths to assist in creating more
portable sites. For example, rather than using something nasty like
$_SERVER['DOCUMENT_ROOT'] which is Apache-specific, I would call
something like Zend::setPath('docs', dirname(__FILE__)) from my
bootstrap index.php file, then whenever I wish to reference the
document root, I simply call Zend::getPath('docs'); This would also
help when setting up various components within the framework like
View scripts, etc.
<?php
require_once('/path/to/Zend.php');
Zend::autoLoad();
Zend::setPath('docs', dirname(__FILE__));
Zend::setPath('app', dirname(Zend::getPath('docs')) . '/app');
$view = new Zend_View;
$view->setScriptPath(Zend::getPath('app') . '/views');
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory(Zend::getPath('app') . '/
controllers')
->dispatch();
?>
This way Zend.php becomes more of a convenience than a dependency.
Although I'm lazy and use the current static methods for the
registry, I'd be happy unlearning bad habits and using a user-created
registry instead.
If eliminating Zend.php is not possible, how about renaming it to
something like Zend_Base so it can be moved into the framework-root
(library) folder?
On 10/6/06, Ralph Schindler <[EMAIL PROTECTED]> wrote:
> The real reason to remove is is that it does not belong. It is a
> mishmash of Registry, Loading, and Debug that will only cause global
> dependencies down the road that will make things worse -- not
better.
>
> I second the motion to remove it.
>
+1 here on reorganizing Zend.php into more logical components.
From an outsiders perspective, I would not know what if anything to
expect from the Zend.php file by its placement in the root. While
much
the framework is shaping up, sticking with a loose coupling, a
simplicty
and common sense approach, I think some refactoring can be done on
Zend.php to fit in with the growing body of code the ZF is.
My suggestions are:
* To remove Zend::registry()/register()/isregistered(), and allow
Zend_Registry handle its own business.
* Move dump() to something like Zend_Debug::dump().. also add
functionality to allow Zend_Debug hook into things like xdebug, etc.
* Move loadClass/loadFile/loadInterface/isReadable to a Zend_Load
class. I am not sold on the isReadable() implementation, and am not
completely sold on if isReadable is needed in loadFile()..
Perhaps the load stuff can stay in Zend.php, this would make Zend.php
the 'Framework Bootstrap file', and its purpose would be clear cut.
But I do think some logic should be added to this file.. in an
existential way.. why is it here?
-ralph
--
Simon Mundy | Director | PEPTOLAB
""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
