I agree completely with Ralf, Simon, Matt R, and others regarding
eliminating the current Zend.php class and splitting it up to achieve
the flexibility and clarity the ZF has become famous for. In fact, I was
pushing for something similar to this in an uncommitted version
pre-0.7. Bill and I brainstormed about these kinds of changes before
0.7, but it was decided to delay consideration until a later date, in
order to get 0.7 done sooner. I've always strongly disliked the old
registry interface currently found in Zend.php. The creation of the
newer Zend_Registry class was a move towards fixing the API without
breaking BC. If we are going to clean things up in time for ZF 1.0, I
certainly vote to do so before ZF 0.9.
Basically, the idea was to have an ultra-light core for "Zend.php"
(really just a minimalistic framework loader / "bootstrap" - not an
application bootstrap), which would then include optional and
non-optional classes necessary for using the ZF. However, these
"pieces" would be grouped under a subdirectory (e.g. "bootstrap")
instead of mixed in with everything else at the top-level.
Some example justifications for splitting / cleaning up Zend.php:
- Why is Zend.php called Zend.php? Cleaning up the organization via
splitting also helps reduce naming confusion amongst beginners.
- Solves the svn externals issue described in detail previously.
- Why should I load a "debug" function with every request?
- How can I add more debug functions for use when I do want/need it
(possibly loaded on-demand, even in my production environment) in a
manner consistent with existing debug functions that is "compatible"
with other related functions other developers might contribute (i.e.
where is the standardization to facilitate community development and
enhancement of framework-level "bootstrap" type features?
- Where is a standard mechanism for developers to add "global"
functionality to their ZF app (e.g. "plugins" for Zend.php)
- Why is the registry accessed via the oddly named functions in
Zend.php? (Yes, BC, but it would be nice to switch to something cleaner.)
- How should developers extend the functionality mixed into the current
Zend.php? Need to plan for the long-term here ...
Cheers,
Gavin
P.S. Zend_Registry is in the core, but the decision was not formalized
to switch to the new, cleaner API (and drop the old API found in the
current Zend.php).
Matthew Ratzloff wrote:
> Ralf,
>
> I cannot agree with you and Ralph more.
>
> Drop Zend.php altogether. Finalize Zend_Registry and move to the core.
> Create Zend/Debug.php and Zend/Loader.php by moving the corresponding
> methods into them, and keep those methods static. Let Zend_Environment
> handle version checking--that's what it's there for.
Simon R Jones wrote:
> +1 with Ralf,
>
> ZF is designed to be used as a component system, so why not drop
Zend.php if
> this is realistic to do so for 0.9. The minor changes required to our
files
> is quite worth it.
>
> best wishes,
> Simon
Ralf Eggert wrote:
> Hi,
>
> I personally think that the proposed renaming of the Zend class to
> Zend_Framework is very misleading. I would expect that a Zend_Framework
> class will set up the whole framework and not be just a funny
> conglomeration of methods who did not find their way to a proper
component.
>
> Here are my suggestions:
>
> - move Zend::register(), Zend::registry(), Zend::isRegistered(),
> Zend::initRegistry() and Zend::__unsetRegistry() to Zend_Registry
>
> - drop Zend::exception() and Zend::loadInterface()
>
> - move Zend::loadClass(), Zend::loadFile() and Zend::isReadable() to
> a new Zend_Loader class
>
> - as suggested by others, move Zend::dump() to Zend_Debug
>
> - the only method I am not sure about yet is Zend::compareVersion() but
> I bet we will find a solution for this as well
>
> Like others I would also suggest to implement these changes before the
> 0.9.0 beta release gets launched.
>
> Best Regards,
>
> Ralf
