As far as I am concerned, the C+V should be flexibile enough (or abstracted/away enough) to allow building with extreme ease servers that support different calling-conventions (eg rest,soap,xmlrpc,plain old html etc) for the same functions. This means: - allowing the input abstraction layer to decide upon current module/action to be executed based on any combination of http headers, get params and request payload - allowing the view to be used for rendering output to be tied either to the action in execution or not (eg tied to the module or to something esle) - allowing to have actions specified as either one class (php file) per action or as one method per action
sorry if this is too low-level for this discussion, I have been wrestling with symfony for 3 days right now, and while it looks very nice and friendly in the beginning, its turning out to be way harder than expected to extend its controller Gaetano > 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 > -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
