Michael Sheakoski wrote:
When you say "inverting it" are you saying to have an Intercepting
Filter outside of the FrontController? Such as in index.php? If it
is outside of the FrontController then you would not be able to do
things like check permissions in a central place because they would be
only be checked for the initial Request before it went into the
FrontController. It seems that the only way to ensure that
permissions are checked in every loop of the FrontController is to use
a Plugin? If you could explain a little more on how you envision the
InterceptingFilter implementation would be used in ZF I would
appreciate it because I am interested in this approach.
The general idea is that it is done outside the Front Controller rather
than inside. The "Filters" are polymorphic so you add as many as
necessary. And they can also be instantiated based on configuration data
as all you need is the class names. The general idea is:
$FilterChain->addFilter(new Zend_Controller_Router() );
$FilterChain->addFilter(new Zend_AccessControl() );
$FilterChain->addFilter(new My_SomethingElse() );
$FilterChain->addFilter(new Zend_Controller_Front('my/conrollers') );
$FilterChain->addFilter(new My_Response() );
$FilterChain->run(new Zend_Http_Request() );
You could also run each Filter manually rather than in the FilterChain.
I guess the complete minimum could be just Request, Router and Front
Controller.
$Router->execute($Request);
$Front->execute($Request);
The idea is low coupling and minimum dependencies -- plus the ability to
add and organize as many things in the chain as necessary. It's just a
different approach that using plugins to the Front Controller as in the
current design.
Of course you can always do the following:
Zend_Controller_Front::run();
and it would create a Router and Request for you.
PS - Perhaps you can see from the first code above why I am for passing
a Registry or ServiceLocator through the chain rather than just the
Request. Once you reach a certain level of complexity, I believe that a
ServiceLocator simplifies things by being a common object container
through the entire program flow.
