cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Sun, 07 Nov 2004 16:21:52 GMT
Joerg Heinicke wrote:
> On 05.11.2004 11:19, Leszek Gawron wrote:
>> Still this is very inconvenient if the model is built for you i.e. 
>> object graph built by hibernate. I would have to make controller 
>> dependant on view view wants to show. Right now I just pass one entity 
>> to view and do not care if view asks for entity fields, entity parent 
>> fields, child fields, anything. If I have hibernate properly set up 
>> the data will be retrieved only when needed.
> 
> 
> But the view is not reusable.
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 :)

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.

I've done a few publishing projects. I agreee with you but only on the 
field of publishing projects where the rendering pipelines are huge and 
usually you produce data in various formats (HTML, PDF, printable HTML).

>> I have project that model have 5-6 depts in parent-child relationship 
>> like:
>> contractor -> surveydefinition -> questioncategory -> 
>> questiondefinition -> alertcategory -> alertdefinition.
>>
>> While displaying list of entities on any level I can choose to add 
>> additional column with link to parent on any level and the only thing 
>> I have to change is the template. Model remains the same.
> 
> 
> If the model changes the view has also to change. 
What I try to emphasize: If the view changes the the model doesn't 
necessarily have to change.

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.

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.

> You all seem to have 
> only just one view in mind. What about having different views for 
> different browsers or devices? While it might be easy for browsers by 
> using XSLT and change here and there a bit, it's nearly impossible for 
> different devices. Who takes control whether to show 5 widgets or 50? 
> Using templates it's only possible by using different templates. And so 
> if the model changes the different templates have also to change. And 
> the templates are still not reusable!
Probably we need either 2 templating languages or a single one covering 
both approaches.

> 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 :)

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message