Hi, Thanks Kore and Pierre for the input! Pierre Minnieur wrote: > Derick Rethans schrieb: >> On Tue, 24 Jun 2008, Kore Nordmann wrote: >>> On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote: >>>> Hi, this is the updated current points to discuss. >>>> Feel free to comment or add any ;) >>>> >>>> HTTP Request Parser >>>> =================== >>>> >>>> Reminder: the request parser creates the abstract input object. >>>> >>>> 0) Should it allow plugins? >>>>> no >>>> 1) Should filter anything? >>>>> no >>>> 2) Should all the GET/POST variables be mixed together? >>>>> yes >>> GET variables should be used for view selection, or maybe selection of >>> the data to display, while POST data should be used for modifications. I >>> wouldn't like that those semantic differences between thse two data >>> arrays are lost in the request parser. >> That is a very good point. I definitely agree with this. > > I definitively aggree with you. > > I'd also suggest to use more of the HTTP protocol available request > methods, e.g. PUT for additions/creations and DELETE for drops/removements. > > This would allow to reuse the same route with four different actions, just > by switching the request methods.
Problem, we want protocol abstraction, and we want protocol dependant variables. All i can think of filling $input->method with the request parser, but depending on that in the controller is definitively not something we want to do. So, we could specify our own methods, that would be translated in the view-handler and request parser. This way, we could use restfull interface transparently from the protocol. Any suggestion? Regards, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
