Hi James! On 01/26/2008 03:35 AM James Pic wrote:
> Tobias Schlitt wrote: >> I think before we can build anything in direction of a Framework >> component/package/whatever, if this comes anytime, creating something >> which realizes MVC (or a similar) architecture makes sense. There are >> many MVC implementations out there, so we should try to keep highly >> focused our needs and build something unique here. >> >> Before anyone goes to implement something in this direction as a >> contribution, I'd like to collect the general expectations here, to keep >> everybody involved. So I'll try to summarize of what I understood are >> the requirements so far. >> >> Target and scope >> ---------------- >> >> If it was for me, the MVC should only cover web environments. While we >> also offer ConsoleTools for building scripts on the shell, this >> environment is not meant to build highly complex applications. However, >> the proposal of James [3] involves request abstraction in a way that >> allows to build applications that are not related to the web environment. >> >> So, the question here: What does everyone need/expect here? > I don't think that I/O abstraction *for* web/cli abstraction is a serious > requirement anymore. Factorisation should be the phase where code to > re-use with another 'runner' should be extracted and independently > implemented/tested. > > However, i expect it to be easy to : > - make a test > - make a request-fixture > - make the output fixture > - run the controller with the request fixture > - assert that the result equals the output-fixture. Yes, I agree that we should keep testing capabilities for the extensions to this component and the applications build upon it in mind during the design phase. But please keep in mind, that we cannot provide the testing environment itself. This does a) not fit into the component and b) our test "component" is not an official component can only be used to test eZ Components. However, we could provide detailed information and possibly some helper classes for the testing of applications build on this component. I hope I understood you correct? <snip /> >> Features >> -------- >> >> MVC means Model-View-Controller architecture and I think this is what >> this components should provide: A basic architecture frame to realize >> web applications inside of it. There shouldn't be any fancy features in >> it in the first place, but it should concentrate on the elementary >> architecture functionality and provide interfaces for all places where >> additional features could be sensible. This will keep the spirit of eZ >> Components to be simple and easily extend able. I especially want to >> point out the simplicity point here. > Should MvcTools use a unified user-project configuration file (with paths, > database access ...) ? Or should this be left to a "Deployment component" ? No, MvcTools (or whatever name it will get ;) should be configurable as any other of our components: Instantiating classes with certain values submitted to the constructor for settings and instantiate and configure option classes for optional configurations. For more information see [4]. The later application configuration layer (meaning to read configuration from config files) and configuring the parts of the MVC accordingly should be part of a potential "Framework" component. But this should not be part of this thread. We should also wait until the Mvc stuff is fixed to start working in something in direction of a framwork bundle. >> The proposal of James Pic [3] already defines the areas that should be >> covered by the first release in terms of interfaces and rudimentary >> implementations. As I found: >> >> - Input abstraction (also see above) >> - Routing >> - Controllers >> - Output abstraction >> >> We also need to think about the following issues when designing those >> features later: >> >> - Re-using of controller code in other controllers > Should re-usable methods really be implemented at the controller-level ? I > think > that re-useable code should be extracted from the controller when refactoring. > In that case, re-using of controller code in other controllers should not be a > need. That is true. Thanks for this hint! :) >> - Error handling > It could be straight-forward to create an error object with a user-message, > tech-message (for example for logging or admin-email if appliable), > additionnal > data-dump, and a 'fallback' controller. I imagine something like this, right. Anyway, normally you don't even want to display "just an error" to the user, but show a valuable page (possibly the application could also guess what the user wanted to do and try to display the correct page) and only inject a small error message into it. To give a short example: You drive a web-video site and someone requests a video that does not exist. In this case you don't just want to display "Video not found" to the user, but also show a list of possibly interessting videos or similar. We need to keep such scenarios in mind during design. Not that such a mechanism needs to be in the component from start, but it must be possible to implement it on basis of the MVC component. >> - Re-routing of action > Personnaly, i enjoy ConsoleTools input-processing features. > Is it possible to factorize ConsoleInput and extract the > options-rules-management > system in another component in order to re-use it in controllers ? No, this is not possible. If we extract the option handling from ConsoleTools this would be a BC break. Beside that, this mechanism is pretty focused on the console environment. > I think that this should be done at the level directly inferior to controllers > (for example : router). I don't know if this is always possible. A controller might start with some operation (e.g. validating a lot of form data) and during this process it determines that there is a failure condition (I explicitly don't use the term error here). In this case (e.g. a form field is missing), it wants to trigger another controller, with additional data (e.g. the form display controller with an additional error message and the field name that has the error). While this example could also be handled by asking the controller, if it can run with the given data, there are also conditions where this does not work (e.g. when database access is involved). I hope I made my point clear enough? Else I could try with another example. >> The question here: Which features would you expect in addition? What >> should the basic implementation provide? Which other issues should be >> kept in mind? >> >> Waiting for a lot of feedback! Feel free to also comment on other >> aspects than the explicit questions. :) >> >> Cheers! >> Toby >> >> [1] http://lists.ez.no/pipermail/components/2006-June/001488.html > The document from last-year [2] is not worth reading to my opinion because > points > are better covered by the most recent document [1]. It still mixes up the MVC part with a framework bundle, which should be 2 different topics, I agree. >> [2] http://lists.ez.no/pipermail/components/2007-November/003209.html >> [3] http://lists.ez.no/pipermail/components/2008-January/003319.html Regards, Toby [4] http://ezcomponents.org/contributing/coding_standards#id26 -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
