Derick Rethans a écrit :
On Thu, 26 Jun 2008, Gaetano Giunta wrote:
Just to be sure: in the shortened example how does the view manager pick
up the correct view handler for the rendering of the response, if the
request obj, carried through the process is to "abstract from the
request protocol and format"?
It would generally need to carry the 1 - the abstracted data, 2 - the
full raw data (get,post,cookies, headers) and 3 - some protocol+format
info in a somehow standardized way.
If we omit part 3, analysis of part 2 has to be done many times over
(view manager and router both might need it in picking up the
appropriate controller/view handler).
If part 3 is only present in a custom subclass of request, ie not
standardized, we force a set of parser+router+viewmanager to be
developed in sync every time... Is this the intended behaviour?
Actually, when you mention under nr 3 - is actually going to be part of
1 - the abstracted data. Unless I got confused. Do you have an example
of data that you expected to see in 3?
Yes, it might be part of 1.
But I still would like to have it separated in a clear way from the
actual data that should be accessed by controller. I fear if we do not
make it 'just a little bit' hard, every controller action coder will
happily take advantage of all the raw data goodies in the request, and
get away with no abstraction/encapsulation...
Ex. of request obj (see previous post for context: multi-protocol ws
server):
methodname = "getStateNamebyNr" (part 1)
methodparams = array(51) (part 1)
requestprotocol = "soap" (this is part nr. 3)
requestacceptedcharset = "utf8" (this is normally kept in part 2 until
the view manager needs it, or also maybe also parsed from http request
headers by the router and stored into part 1?)
requestacceptedcompression = array("gzip","compress") (just like the one
above)
requestacceptedlanguage = etc...
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
