Hi James, Am Freitag, 22. Februar 2008 schrieben Sie: > 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.
Don't know how other systems solve that. In eZ Publish those "zones" are just some templates that are included in page_layout.tpl. Things like tree menu or a box with latest news are build via template functions that fetch and represent the data. You can argue that this is a little bit against strict MVC as there is some logic inside the templates. But it is somehow intuitive. Also you do not need to touch the "core" of your application or change some configs if you want to add a new box/zone. > 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. Hm, the example has some pitfalls: - Perhaps it's better to redirect (via a redirect parameter) to another request after doing actions like adding something to a cart. So only the cart controller is used in the first run. The cart action finds the redirect parameter and instructs the router to redirect to that reqeust. (If you do not want to redirect, you could perhaps rerun the router with that redirect parameter. But the important thing is that the cart controller/add action decides that.) - In case of failure in the cart-add action, the controller/action has full controll what to do. It can redirect to some error page and (if wanted:) propagate the original redirect parameter to that page as well. So when the user solved the problem, he comes to the original planned page. Following your idea, the view manager has to decide, that the main content is not the browse_items part but the action's failure... - What happens if the user manipulates the request and adds or removes controllers? Won't this result in a mess or at least unneaded work on server side? (If you do not have a really fine-grained rule set like described below.) > 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. - I guess, it's not that easy to configure/implement the getControllers() function: * if it is an AJAX request: only use the requested controller * if it is an HTML request: please allways add dynamic_menu controller * if it is an HTML request and adds something to cart: check if there is a requested main controller and use it; if not maincontroller defaults to XY * ... I guess, this gets really complicated to define and interpret. > 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 ? > > > Encapsulate controller multiplicity to avoid the overhead when only > one is used ? Sorry, I'm not sure, if I got the questions. But I still think there is probably no need for multiplicity :-) > > - 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. I'm not sure, if adding the output solves the problem I mentioned. Of course, you'd need the output in your example below in case of failure to probably fallback to an HTML error page. But read on below... > > 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 ? I see your point about formats. Probably I'd implement an HTTP (or WebGui) view handler and not different HTML, PDF, VCard, ... handlers. This could check the format (depending on requested format and output state) and redirect the output handling to some sub-handler. So even here it's not the router's job and it is protocoll independent. Have a nice day Thomas > > > > 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. > > Cheers, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
