Hi Thomas,
Thanks for your revelant work !
Thomas Nunninger wrote:
> - I'm still not sure if we need controller multiplicity at all. I guess,
> it's a problem of my limited phantasie/experience as I can't imagine a
> situation where I need it. But if we have only one controller, we only
> have one output - I guess, this will reduce complexity.
>
> The only situation, I can imagine you could use it, is a normal portal
> web site, where you have the main content area and e.g. left/right a
> menu, some info boxes, ... that are content independant. But I wouldn't
> use multiple controllers here because this is protocoll/interface
> depending: you want to have a menu in the HTML frontend but perhaps not
> in the SOAP or whatever interface.
>
> In my opinion, you have one request and this request is handled via one
> controller. (If you have a request that includes several sub-request,
> you should not handle this via router - that only has the input to
> decide on the used controller(s) - but in the controller, that can call
> some sub-controllers/-processes.
>
> Can you give a real world example where you know (from the beginning/
> the request input) that you need more than one controller?
Actually, you'd need one "controller" and several so-called "zones" to
build the view of the webportal.
If that's what you mean, why not abstract "zones" from other "controllers"
making it all implement the same interface ?
This should allow more flexibility and re-usability ...
Basic case :
0) Client requests
cart[add]=123&main[ctrl]=browse_items&browse_items[sort]=price
1) Request parser makes an input object from this, which has the same infos.
2) Router selects controllers : cart, browse_items and dynamic_menu.
3) Each are run and there are 3 output-objects.
4) The view-manager parses templates with the output-objects and creates the
response.
Ajax case :
0) Client requests : main[ctrl]=cart&cart[remove]=123&cart[quantity]=3
1) Request parser makes an input object from this, which has the same infos.
2) Router selects controller : cart
3) cart controller is run and the output object is there.
4) The view-manager parses the templates with the output objects and creates the
response.
The soap case is indeed pretty much like the ajax case because it has one single
controller.
If multiplicity must be encapsulated, i don't think that it's in a decorator
controller, what's your idea ?
.mutt/tmp/mutt-paloma-1000-6427-104
19,1 Top
:set nonumber
controller, what's your idea ?
Encapsulate controller multiplicity to avoid the overhead when only one is
used ?
>
> - Regarding the router/view manager: If I understood correctly, a view
> manager is protocoll-dependant. On which base could the router decide
> to fetch a view manager? If I'm correct, it has the abstract input
> object only.
I remember that Kore pointed this.
Could this be solved by using input *and* output objects in the view-manager to
select the handlers ? I fixed the design docs.
>
> Regarding this issue and the question about the need of controller
> multiplicity: perhaps we do not need a view manager but only view
> handlers?
If GET[format] = pdf, for example, isn't it the responsability of the
view-manager to select the pdf view-handler ?
>
>
> > > Open issues
> > > ===========
> > >
> > > Should the router be selected by a router manager?
> > > --------------------------------------------------
> > >
> > > The router could be selected by a router-manager. In that case,
> > > some routing mechanism should be in the router manager.
> > > Router-manager shouldn't be implemented, routers should be
> > > factorized instead.
> >
> > I don't see why there should be 2 routers for one same protocol
> > either, although this obviously seem a correct design pattern.
> > In the rare cases where several routers should be managed, this can
> > be done in the index.php file for example, as a temporary solution
> > before factorization.
>
> Is the router protocol dependant? I thought, only the input parser and
> the view handler should be. Rereading the documentation, I see, that
> you talk about an ezcMvcUrlUserInputRouter in the example. Is this
> really neccesary?
Actually, ezcMvcUrlUserInputRouter is just a router that *could* come
with ezcMvcUrlUserInputRequestParser.
We have not though of abstracting the protocol at the router-level afaik, that's
a good point.
Good day and thanks again,
James.
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
