I agree that the ZF would benefit by having the container type objects
share a common interface. Whether any of these classes inherit a basic
array/property class is a separate question that should be made on a
case by case basis. But having a common interface standard would easy
learning the ZF by making container interfaces predictable.
Regarding the FilterChain, I originally proposed the FilterChain and
Validator because I believe they are a better foundation on which to
build stuff than the monolithic and procedural Filter and Filter_Input
classes are. Because each Filter and Rule is its own class it is both
infinitely extensible, yet you only include what you use. I actually
originally created and implementation of the Filter and Input_Filter
classes that was built upon Filter and Rule classes. It was very easy
and would simplify testing and perhaps performance.
As a sidenote, the FilterChain class could also be easily adapted to
optionally be used to implement Intercepting Filter containing things
like Access Control, Router and Front Controller objects. It is very
multi-purpose. The FilterChain is really just a chain that you pass a
Request object through and each Filter operates on the Request. Likewise
the Validator is a chain of Rules that check the Request. These classes
make it pretty easy to create Form and Application Controllers.
The proposal I did a while back and has never been updated and needs a
little work. I noticed that is has been demoted back to proposed from
under review.
Simon Mundy wrote:
Hi there Ziffers
Like many others, I have encountered many areas of overlap within the
Zend Framework when I've been outlining the skeletons for components.
The Zend_Acl component uses a form of 'container' or 'hash' that is
almost functionally identical to that of Zend_Config, as does
Zend_Environment. The proposed Zend_Form also needs a similar
container, and Ralf and I were examining the Zend_FilterChain
component as a means of providing filtering/validation.
To that end, I wanted to see if we had reached some conclusion (or
even progression!) regarding these two ZF 'primitives'.
I know Zend_Hash was nominated as a name but wasn't terribly well
received. I personally would be happier with Zend_Container - an
abstract class that implements Countable, Iterable and provides
overloading for public properties. It could possible define the stored
data as a private property to ensure that all children of
Zend_Container were well behaved and used the get() and set() methods
to manipulate and iterate through this data rather than simply
allowing access to the array. Thoughts?
Other components that could possible use Zend_Container as a primitive
are:-
- Zend_Config
- Zend_Db_Table_Rowset
- Zend_Http_Request
- Zend_Acl
- ...anything else that requires a resultset...
Is there a timeframe to get this rolling, as I'd like to refactor my
components ASAP to avoid duplication and reduce the amount of unit
testing needed or each separate component.
Also the Zend_FilterChain has been referenced by a lot of
discussions/proposals as well but no real steps forward to
implementing it. Revisiting it today, I'm not sure if an abstract
class would be necessary - it seems that it may be of more use to
implement as an interface. The 'observed' component (be it a
Zend_Acl_Aco or a Zend_Form_Field) will most likely extend a container
so it will not always be practical to use a FilterChain as a
standalone abstracted class.
Any thoughts on this? I look forward to Christopher's comments, of
course, being the driving force behind the FilterChain, as well as
anyone else who has an immediate need for these two ZF components
Cheerio
--
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
