Hello everybody, 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
> Open issues > =========== > > Definition of the ezcMvcController interface > -------------------------------------------- > > The description and definition of the ezcMvcController interface should be > reworked. The expected behaviour and API of classes implementing this > interface should be described in more details. > 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. > 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. > Shipping of example-implementations > ----------------------------------- > The section `Design overview`_ states that very basic implementations of the > provided interfaces should be shipped with the component. It must be decided > if these implementations should be part of the components source code itself > or should deal as documentation (and therefore reside in the docs/ directory > instead of src/). That's just examples, tieins should be done soon anyway, so there is no need to worry about using poorly-featured implementations. > Tiein components > ---------------- > > ezcMvcToolsTemplateTiein should include an extension with a function to > generate urls for ezcMvcToolsUrlTiein; how to handle this dependency paradox? Maybe this makes the idea of a framework component that escapes from the dependency limitation standart like an interresting idea. Any better idea respecting the dependency limitation is welcome. > Should controllers multiplicity be encapsulated at all ? > -------------------------------------------------------- > There is no need to use anything better than a simple associative array for > the list of selected controllers returned by the router at the moment. The design pattern has made it's proofs and is seductive though, what do you think ? > Possible system conceptions > =========================== > > Encapsulate view handler multiplicity into a view-manager? > ---------------------------------------------------------- > > This will free the router and user-space from rendering tasks, particularely > useful when using several controllers at once. I think that the component > should provide such a class, letting to concentrate on working on view > handlers. Any pitfall ? > Delegate most of the high-level mechanisms to the router? > --------------------------------------------------------- I don't think it's a good idea because that's not the job of the router. The user is free to implement these mechanisms in the router or a separate class though. Thanks in advance for your feedback. You should understand that the time that you spend on MvcTools today should be very profitable tomorrow. It is very flexible because there are several levels of encapsulation, the re-usability of controllers/view-handlers/view-managers/request-parsers/routers will allow to concentrate on more challenging parts when developping applications. What we're doing is pushing eZ Components to a higher level, i really don't see any pitfalls in such an idea in itself - i even think that this has a fair business-value *if done correctly*. We really need your feedback to make sure that this idea is concretized in a viable way for everybody. Cheers, James. -- James Pic -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
