Hi, Am Samstag, 23. Februar 2008 schrieb James Pic: > 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.
As you can create custom template functions, I see no limits. The only important thing is that you have enough information (in eZ Publish this are e.g. the currennt node/object, the user and some other). > > > 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 ? No, it's about usability: what if the user presses Reload just to update a live ticker in the top right info box? He will add a new item to the shopping cart. What if it was not adding an item to a shopping cart but checking out the cart finally or sending some message? [snip] > > > 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 ? Why do you want to abstract input and output if you make a protocoll depending router. Will the routing logic differ? The only difference between several protocolls I see at the moment is the controller multiplicity, the logic to fetch this or that additional(!) controller(s). > > > > 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. Something like that. I guess, you got me right, but just want to explain again: The WebGui handler could check the output. If the requested output format is pdf and there was no error, it delegates the output to a sub handler rendering PDF. HTTP handler is no good wording, as SOAP, AJAX and many other things are handled via HTTP as well. WebGui points to the fact that the user uses a browser to request a url. If you have a SOAP view handler it points to the fact that a programm is interacting via function calls and AJAX relates to calls in the background of the browser. Probably the WebGui handler is the most complex one as it needs to decide if it outputs HTML or PDF or ... If you have a SOAP or AJAX call, the output format/mime type is clear. Finally: I have no problem if you implement controller multiplicity - I guess, I won't use it. :-) And I can write my one "singleton" router. But the question is: do you really need it or are your use cases better solved in another way (making the MvcTools not too complicated). It would be really nice, to hear others' opinions on that... Have a nice weekend Thomas -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
