Hi, > We have worked on the design doc on IRC yesterday and it's ready for > discussion. It does not meet all requirements but we should agree on > what has been done before talking about the basic error controller > and such. It's online on > http://svn.ez.no/svn/ezcomponents/experimental/MvcTools/design/design >.txt
thanks for the document. Some general points first: - 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? - Some new idea regarding the MvcOutput: it could be a nice idea if the output object contains a response state like the HTTP response codes. This response code should be abstracted as well and mapped (by the view manager/handler?) to a correct protocoll response code. Of course it is possible to do this myself as the output object is flexible - but it would be nice, to ship it with the component. The biggest problem could be to find a set of states. Implementation-wise, I think this is one class having many constants and some protocoll-specific mapping classes for different protocolls. - 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. Regarding this issue and the question about the need of controller multiplicity: perhaps we do not need a view manager but only view handlers? > > Open issues > > =========== > > > > Should the MVC implementation take care of actions/sub-controllers? > > ------------------------------------------------------------------- > > > > Controllers have a method looking like : run( ezcMvcInput $input ) > > It's up to the controller to figure it's action using $input. > > It's possible that some controllers use actions or sub-controllers. > For example, a CRUD controller should have methods "delete" and > "create". Should these methods be selected by the controller itself > or by the router ? > > In many implementation of MVC, each controller public method is an > "action" and the router takes care of selecting the method name using > the HTTP GET variable "action" or something like that. > I see pitfalls of such an implementation : > - controller's common set-up and tear-down should be in protected > methods, which should *not* be tested. > - selecting an action using 2 input variables must be done in the > router. - selecting an action using an external value, like results > from a database, must be done in the router. > > I'm convinced that the router should only care about selecting the > controller, even though i see one possible pitfall : > - complex controllers will have "action routing" code. > > But, i'm convinced by the benefits : > - setting up and tearing down can be tested by stubbing the "action" > execution in the controller, > - "action" routing can be done with more visibility, and is not > limited to input-variables. I agree with you to select the action in the controller. In fact, I didn't think about choosing it from the router (even we use ZF at work). That way, you can have different styles of fetching an action in each controller. And if you want to have it done the same way in all controllers, you could e.g. write a controller base class that handles the action selection. > > 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? Have a nice day Thomas -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
