Derick Rethans a écrit :
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.
I think I second that. It sounds unclean compared to the other proposed
approach, but it ends up in being far more flexible, ie. users could
build whacky routers/view managers without getting lost in a maze of
subclasses.
As an example, a typical (?) controller I built tries to answer to
multiple-protocol webservice calls, sniffing in order something like this:
- GET and no query string => route to ws documentation intro page in html
- GET and query string => route to ws action, using rest decoding of
params and output view (another option: route to html doc of a single
webservice and/or in a given language, and/or in a given format etc...)
- POST: check out request http headers to find out if there is any soap
header => route to ws action, with soap view
- POST with application/json request http content-type => route to ws
with jsonrpc view
- POST with form-encoded content => route to ws action, using rest view
- POST with xml request http content-type => route to ws with xmlrpc view
- POST with no discernible http headers => route to ws using jsonrpc (if
it decodes the request successfully)
this means that GET, POST (in its RAW_DATA form) and http headers could
all be needed for the router to make its informed decision.
Another unconventional router could be used to parse parameters given
from the CLI - I just hate that symfony now deprecates using dispatch()
for cli stuff...
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
