Hello everybody ! Thanks for reading my comment on Tobias feedback.
Tobias Schlitt wrote: > Hi all! > > Please don't stop reading here, although this email is a bit longer. It > is not as long as you think right now! :) > > I took some time and reviewed the discussions and proposals that were > posted to this list regarding a "Framework" or "MVC" component. There > was some brainstorming [1] a longer time ago about this topic, last year > James Pic proposed a Framework component [2] and posted requirements for > a component called MvcTools [3] earlier this month. > > Thanks a lot, especially to James, for these ideas and postings! There > are many good points in here and I would be more than happy to get > something like this as a contribution. Thanks for your quality feedback and cheers ! > > 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. > > In addition, as I mentioned before, I think that building an MVC > component should come before creating something like a "Framework" > package/component/whatever. Therefore, this component should neither > provide any automation facilities (e.g. code generation) nor integration > with components that are not explicitly needed by it (e.g. > Configuration, Authentication or Database). Integration with such > components could a) be build using a tie-in or b) be part of whatever > "Framework" stuff that might be created in future. > > Agreed? > > 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" ? > > 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. > - 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. > - 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 ? I think that this should be done at the level directly inferior to controllers (for example : router). > > 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]. > [2] http://lists.ez.no/pipermail/components/2007-November/003209.html > [3] http://lists.ez.no/pipermail/components/2008-January/003319.html Cheers, James -- James Pic GPG Key : 13185F50x8 / AEE2 CC15 8FF8 339C 23AC 5A91 491B 1638 1318 5F58 Downloadable on http://jamespic.com/pubkey.asc
pgpdropKhGf1U.pgp
Description: PGP signature
-- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
