[RT] Cocoon MVC+

[Nicola Ken Barozzi <ni...@apache.org>]

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Cocoon MVC+

[Jeremy Aston <je...@yahoo.co.uk>]

Great RT! 
I've always thought that Cocoon enables the development of apps that follow a (if slightly hybrid) MVC pattern and overall I think that you've hit the nail on the head.  One area that I think is interesting is where generators fit.  On the one hand they are intrinsic to the view in as much as they are the first step in obtaining a view however they also are the most likely point of interface with the model.  My guess is that most people, until told otherwise, will do a hell of lot of processing inside a generator (typically an XSP with loads of embedded SQL) that reflects the business process being modeled.  Of course alternatives to this would be to have the generator feed off a stored procedure, EJB etc - i/e anything that abstracts the interface to the business rules and db away from the generator. 
My gut feel is that although Cocoon does allow the developer to feed different views from one generator (via different transformers and serialisers) there is likely to be alot of mix of logic/db access/processing going on in a generator simply because of how developers might use XSP.  I have seen it in my own team where all the guys moving from ASP type backgrounds mix SQL in with XSP logic on the assumption that just so long as you chuck a stream of XML down the stream you are ok.  Some of the early XSPs I've done are a maintenance nightmare!  Logicsheets help as does education, building bespoke generators in Java and some design patterns but this still seems to be a grey area (at least in my head!). 
Admittedly this is a POV that is moulded by access to RDBMS but that must be where most Cocoon developers are. 
jez 
 
  Nicola Ken Barozzi <ni...@apache.org> wrote: 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org



---------------------------------
Relive the FIFA World Cup goals with exclusive video highlights!

http://fifaworldcup.yahoo.com/fc/en