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. > >> 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. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
