Now I get it why some cocooners have such a different opinion. I think there are two worlds that cocoon covers:
- xml publishing, dynamic sites but with not that much business logic. Here the most work is put into data aggregation and rendering. I think your opinion represents this world.
- web applications, totally dynamic, a lot of business logic. Most work is put into model and business logic. The controller is also significantly more complex. View is the least sophisticated here. This is my world :)
Actually, I live in yet a different world. We have a single webapp with a lot of business logic (in an EJB tier, though). However the webapp can take on 1600 look and feels depending on how our customers want to view the data. They can change what columns appear, what order the columns are in, whether or not to show a column that has no data, in addition to the "normal" things such as changing the graphics and labels on the page, or how the navigation is laid out. In fact, Cocoon's ability to do this is exactly why it was chosen. In this world everything is complex, including the presentation logic.
I am developing web applications. That is why the main concern for me is the MODEL reusability. I do not care about the view reusability as almost everything is modelled in html (For styling I use single site2html.xsl which applies common styles, toolbar and menu). For apps I seldom use aggregation and 99% views are JX generated.
We use tons of aggregation. We aren't using Cocoon forms yet and only a little JX.
What I try to emphasize: If the view changes the the model doesn't necessarily have to change.
I couldn't agree more. In fact, we have several views of the same model.
For web applications:
- the model is the first to be agreed upon/designed/implemented
- the model is the core of the application and most weight is shifted in that direction
- the model is strongly typed, has a lot of constraints. Almost whole model consists of POJOS.
- the model does not change much. If it does it's much bigger problem than just updating the views because it involves a lot of business logic to be changed.
Maybe this is just a different way to say the same thing. In our environment we designed and developed the business entities first independent of any view. We then determined what DTOs needed to be transfered to the presentation tier based upon the data the use cases would need, sharing DTOs where that is possible. Then the Business Delegates/Session Facades were implemented to return those DTOs. At the same time the View was implemented using mock DTOs. Finally the two tiers were tied together.
That is why I need my model (especially built by hibernate) to be clear and reusable. Not the view.
Also I need the rendering logic to be applied in the view and not earlier. I need to be able to choose a convertor during view generation:
- I might want to show property value in plain text in one place (for editing) and in the same view pretty printed below.
- I do not want all Integers < 0 to be rendered red. This is based on the context. It is also inconvenient to put that info into the model as there may be a lot of orthogonal views of the same data. The model would have to support everyone.
I concur. Not only is it inconvenient to put that info into the model, it is inappropriate. It as a violation of SOC.
Shall the view decide it? Even with renderers/converters this makes it being not reusable. As Terrence Parr wrote: The view should be reusable with a completely different model. The configuration must happen externally, i.e. neither in model nor in view.
This clearly makes the difference for web applications: The model should be reusable with a completely different view :)
Looks like we all agree on this.
