Hello everybody ! Tobias Schlitt wrote: > Hi! > > On 01/25/2008 12:34 PM Gaetano Giunta wrote: > > As far as I am concerned, the C+V should be flexibile enough (or > > abstracted/away enough) to allow building with extreme ease servers that > > support different calling-conventions (eg rest,soap,xmlrpc,plain old > > html etc) for the same functions. > > > This means: > > - allowing the input abstraction layer to decide upon current > > module/action to be executed based on any combination of http headers, > > get params and request payload > > I think this is the thing we need to abstract: The input abstraction > should abstract from the GET/POST/... data, headers and things, so that > the router can decide which controller to use. Or did I get you wrong? >
Controllers should use an abstracted input object. The input object should be buildable from differrent request protocols. > > - allowing the view to be used for rendering output to be tied either to > > the action in execution or not (eg tied to the module or to something esle) > > I don't really get this one. Could you elaborate some more here, please? This looks like controller re-routing to me. > > > - allowing to have actions specified as either one class (php file) per > > action or as one method per action > > This could depend on the router implementation, I think. However, I > personally would favor to have it defined once, for consistency. > It should be quiet straight-forward to make a controller using classes for actions anyway. > > sorry if this is too low-level for this discussion, I have been > > wrestling with symfony for 3 days right now, and while it looks very > > nice and friendly in the beginning, its turning out to be way harder > > than expected to extend its controller > > Your input is really valuable. It would be great if you could invest > some more time to discuss the requirements and design of this stuff with > us here. :) > Thank you very much for your revelant feedback, see you later on the ml, regards, James.
pgpP0IV7wmwTp.pgp
Description: PGP signature
-- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
