Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <418E5A05.6080302@dslextreme.com>
Date: Sun, 07 Nov 2004 09:23:17 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Attribute Rendering and CForms Convertors
References: <5E091A68F794974CAF431CA31F5AF2CC11E99F@server.bizzdesign.nl>
 <4187D02F.9090209@nada.kth.se> <418A3C62.7020800@apache.org>
 <418B4E93.5050808@nada.kth.se> <418B53C3.9020000@mobilebox.pl>
 <418DF5D1.6060005@gmx.de> <418E4BA0.2000206@mobilebox.pl>
In-Reply-To: <418E4BA0.2000206@mobilebox.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Leszek Gawron wrote: 

> 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.