Previously, it has been said that MVC doesn't correctly relate with Web Applications; nevertheless Cocoon now seems to be able to make a real MVC server.
Why is defining MVC in Cocoon so important IMO? Essentially an image and comunication issue. * Image because we are being compared to Struts and Maverik by users that follow the MVC pattern (hype or not they do) heavily. * Communication, because MVC is easy to understand conceptually, and makes it easier to describe what Cocoon can do. To see what Sun says about MVC, I've read the lueprints, and here is the talk about MVC: http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html. Below are the concepts and how they can map IMHO to Cocoon ones: "The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. " Cocoon doesn't have model facilities. It can use any model done in Java, but has no preferred or standard support for any. "A view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. " These are the pipelines. Generator-Transformer-Serializer. This makes it clear how using them to process data is inappropriate. "A controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view. " We have one front-controller, the sitemap, that operates on predefined semantics: matchers, selectors, actions, and now flows. These are more fine grained controllers, that are assembled as programming blocks in the front-controller. But... Cocoon has an advantage on normal MVC web systems: continuations. The flows are special controllers, because they span multiple requests, and basically expose clearly client-server transactions. This is the reason why I called it MVC+ So, could this be a good enough description? Should we put it in the documentation? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
