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. 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? 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. 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 - Error handling - Re-routing of actions The question here: Which features would you expect in addition? What should the basic implementation provide? Which other issues should be kept in mind? Component integration --------------------- eZ Components already provide some components that are useful when implementing an MVC. However, one basic goal of eZ Components is to keep each component as independent as possible and to realize dependencies through tie-ins. Therefore the mechanisms realized in an MVC component should be that far abstracted, that other components can be tied in and provide only very basic implementations on its own. This also allows users to implement their own mechanisms. I identified the following components to be related here: - Template (view) - UserInput (routing) - Url (routing) PersistentObject is also valuable for the model part of MVC, but does not need any kind of dependency, since it operates pretty independent. For the eZ Components book Kore and me implemented a pretty different approach to MVC using the SignalSlot component (more as an example to use this one than as a really usable MVC). I'm not sure if this could also deal for a real-world approach. Are there more components to be possibly integrated? Do we need any hard dependencies? 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 [2] http://lists.ez.no/pipermail/components/2007-November/003209.html [3] http://lists.ez.no/pipermail/components/2008-January/003319.html -- 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 Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
