cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Sun, 07 Nov 2004 20:55:05 GMT
On 07.11.2004 17:21, 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).

Ah, no, IMO these are not two worlds, but two parts of one world. Though 
I have worked mostly on the presentation layer almost all our projects 
were also web applications. And I don't see why I should abstain from 
reusing my presentation layer while the model is reused.

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

Of course. As I wrote the model must not depend on 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.

But why introducing dependencies into the view and not externally? How 
do you want to ensure consistent view over all templates or even over 
different applications in a software product line?

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

We need both!

Joerg


Mime
View raw message