Hi! On 07/01/2008 11:17 AM Derick Rethans wrote: > On Mon, 30 Jun 2008, Tobias Schlitt wrote: >> On 06/30/2008 11:52 AM Derick Rethans wrote: >>> On Mon, 30 Jun 2008, Tobias Schlitt wrote: >>>> On 06/30/2008 12:42 AM James Pic wrote:
>>>>> Tobias Schlitt wrote: >>>>>> ezcMvcRequestFilter >>>>>> ------------------- >>>>>> >>>>>> The filters are described to be used in a method named >>>>>> ezcMvcController->runRequestFilters(), while this method should be >>>>>> called by ezcMvcController->run(). It does make little sense to me to >>>>>> mention that a method ezcMvcController->runRequestFilters() should be >>>>>> implemented at all, if the controller calls the filter itself. >>>>>> >>>>>> Instead I would suggest to design it in either of the following ways: >>>>>> >>>>>> a) Remove the ezcMvcController->runRequestFilters() part and just >>>>>> mention that filters should be run by the controller. >>>>>> b) Require the method ezcMvcController->runRequestFilters() in the >>>>>> interface and make it be run by the request builder. >>>>> Don't you mean that the request maker should run the filters? >>>>> Should the selection of filters depend on the controller or the request >>>>> builder? >>>> The object running the controller should do it. :) >>> That poses a problem. It means that the filter selection now has to be >>> done in the dispatcher, where it clearly belongs to the controller. It >>> also means that might you have to implement the filter chains multiple >>> times. >> No, the dispatcher just issues the filtering methods, instead of leaving >> this to the controllers run() method. Dispatcher code: >> >> // ... create request and controller >> >> $controller->runRequestFilers( $request ); >> $result = $controller->run( $request ); >> $controller->runResultFilters( $result ); >> >> // view handling... > But why do you want this? There is no reason why the dispatcher should > do this, as it can all be done in the run() method. The abstract > ezcMvcController class provides the run() method, that in order: runs > the request filters, figures out which action to call from the request > object (with a "findAction( $request )" method ), runs the action with > its parameters and then runs the result > filters. The run() method you should not have to overload yourself - and > thus the filters are always run - so why do you want to do this in the > dispatcher instead? As I said, this also works. For me the run*Filters() calls still belong to the dispatcher, so that people can also overload the run method without preventing the filters to be executed (by mistake). I can imagine a lot of cases, where this can lead to strange results and having the code in a central place for all imaginable controllers in an application makes sense for me. You always want the filters to be executed, no matter of the controller implementation. So why put these calls into the controller itself, when they can be run by the higher level instance? However, this discussion lasts too long. :) If you are convinced having the run() method call the filters is the better way, keep it like that. I stated my opinion here multiple times. If it's just me to think the proposed solution is designwise cleaner, I'm fine with being overruled. :) Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
