Even if not everyone wants the features below, certainly many developers
will implement similar capabilities, if not found in the ZF. My
intention behind http://framework.zend.com/wiki/x/j1 is merely to find a
mutually-agreeable way to support the possibility of adding
*utility-like* features (e.g. the ones suggested below) without bloating
up a "hello world" ZF app. I'm just trying to get the ball rolling, so
if some of you have strong opinions, I encourage you to directly edit or
comment on the proposal above.
There are many possible approaches (I'm vague on purpose, because I
don't want to get stuck on any particular approach):
- multiple sub-directories
- single collective subdirectory
- packaging of the related utility functions into files, classes, or
subclasses implementing extensions, "modules", or "packages", or
"plugins" in some form or other for Zend.php
Personally, I'm not as concerned about the mechanism used to dynamically
add "utility" functions to the "bootstrap", so long as there is
something better than just dumping more functions into the Zend class in
Zend.php. I'm also more concerned about future additions than any
"problems" posed by current functionality in Zend.php, although a
cleanup/reorganization before ZF 1.0 would be nice.
Cheers,
Gavin
P.S.
> .. it's possible to have customized registries for different parts of
large ... Passing it as an object ...
You read my mind .. I have high hopes that Zend_Registry will become
more useful and used in future versions of the ZF, per your example ;)
Matthew Ratzloff wrote:
For what it's worth, it is ideal to retain the Zend.php instead of
splitting it up so the framework could build more utility functions into
it in future - that does not fit anywhere. How about renaming it to
Zend_Util, instead?
I can't imagine any utility methods that would be needed that could not be
put into a more full-fledged class. Looking at the existing methods:
Zend::loadClass() => Zend_FileSystem::loadClass()
Zend_FileSystem could include recursive directory iterators, regular
expressions-based file manipulation, etc.
Zend::dump() => Zend_Debug::dump()
Zend_Debug could include a whole host of additional debugging information,
interaction with Zend_Log for trace messages, pseudo-breakpoints, etc.
And Zend_Registry already exists. With a separate Zend_Registry class,
it's possible to have customized registries for different parts of large
applications--providing a scaled-down version of the registry for plug-in
developers, for instance. Passing it as an object through the
controller's setParam() method also makes it easier to test, say,
individual actions.
In all cases, the framework benefits from individual, specialized components.
If we keep Zend.php (or whatever it would become), I think it'll be there
forever. If it were removed at some point in the future, it would really
slow adoption of whatever version removed it. People will have
Zend::register() or Zend::loadClass() calls throughout their applications
and be sluggish to invest the time in changing them. It's like PHP
deciding to change array declaration to $array = [1, 2, 3] and deprecating
(and eventually removing) the array() construct. They could never do it.
-Matt
