On Tue, 24 Jun 2008, Derick Rethans wrote: > On Tue, 24 Jun 2008, James Pic wrote: > > > Tobias Schlitt wrote: > > > > > > On 06/24/2008 01:59 PM James Pic wrote: > > > > We want protocol specific variables in the protocol specific > > > > view-handler. > > > > That means, that the request parser should take some variables and put > > > > it > > > > somewhere for the view-manager later. > > > > > > > OPtions we could think of: > > > > - add protocol specific variables in the input object, > > > > - make two input objects, a raw input object and a protocol abstract > > > > input > > > > object > > > > > > I'd go for the first version. In case more information must be > > > transported, one can extend the input object. > > Other possibility:: > > > > <?php > > // 0) This request object has protocol specific stuff > > $request = $requestParser->createRequest(); > > > > // 1) Make the abstract input object > > $input = $request::createInput(); > > The $input object could be an child class of the request input object, > so that you still *could* pass it to the controller, but you really > shouldn't. This makes this more flexible for the cases where you want it > to, but you'd lose the nice encapsulation. By creating an input object > then you make it clean, but more restrictive.
We just had a little discussion, and decided not to go with this. We'd still "abstract" some of the raw request data, but always make the raw request data available through a "raw" array. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
