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... >>>> ezcMvcRequest >>>> ------------- >>>> >>>> The class defines a $content and a $variables attribute. Where is the >>>> difference here? >>>> >>>> In case of GET/POST requests, there are only variables, files, etc. So >>>> not content. In case of PUT requests, there might be content, but no >>>> variables. Shouldn't this be unified? In case of a SOAP request, there >>>> are only variables, too, but no content. >>> Sounds like a good idea, do you mean that a property like $request->data >>> would >>> either be an array of variables, either a main content? What is your exact >>> proposal? >> I'm not sure here, it's quite hard to design unless we have a good >> overview which are the potential formats of incoming content. Maybe you >> could create a little list for this in the requirements document, so we >> get an overview what we can expect here? > It should be in a different requirements doc - one for each request > builder. I think the common requirements for the abstract request class (ezcMvcRequest) need to go into the global requirements document. The requirements for the bulding process should go into dedicated docs, I agree. 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
