Hi Thomas, Thomas Nunninger wrote: > Am Freitag, 22. Februar 2008 schrieben Sie: > > 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. >
That's exactly what i'm talking about. The other problem with zones is that their business-logic is limited to what the template is allowed to use. > > 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.) Why should the cart controller redirect after each action ? Is this really ergonomic ? Isn't this more a workaround when *not* being able to use several controllers ? > > - 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... I argee that any controller should be able to redirect to an error page. In this case, "main" was just a specification for the view-manager : use "browse_items" in $main. You don't have to make it this way with MvcTools. > > - 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.) > I agree that the router should not choose the controllers by only reading the input object. To illustrate this in the example, "dynamic_menu" is selected though nothing involves it in the request, and "cart" would have been selected as well "anyway", and a default controller would have been choosed for $main. > > 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. I'd use another router to handle ajax requests, and probably another view- manager (xml output?). Why not use another router/view-manager (xml output?) for ajax requests ? > > > > 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. Do you mean an HTTP view manager and several view handlers usable with other view managers ? I agree, i think it's good. Cheers, James. -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
