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 10:15:45 GMT
On 05.11.2004 11:19, Leszek Gawron wrote:

>> Terence Parr sugests that test like "$bloodPressure<120" in the view 
>> should be performed in the model and tested in the view like 
>> "!$bloodPressureOk". He even says that:
>>
>> Even simple tests that make negative values red should be
>> computed in the model; the right level of abstraction is usually
>> something higher level such as “department x is losing
>> money.”
> 
> 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.

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

> If I had to prepare data for view in such detailed manner as Terence 
> proposes I would have to:
> - break whole entity tree
> - forget about lazy-loading
> - fetch data on each level separately
> - prepare some kind of DTOs that would apply "view needs" to data stored 
> in database
> - build another object graph only for the sake of one view
> and above all:
> - change my model every time I change view template

Of course that's neither a way. The model *must* be independent of the 
view. But isn't this what the renderers/converters are about?

> and still: I do not see any gain if I did that. The code is boasted, 
> harder to maintain as more dependencies are introduced and much more buggy.
> 
> Shouldn't SoC help making the app clearer and more flexible instead of 
> making it harder?

Of course. You separate into model, view and inbetween renderers. That's 
what Terrence Parr suggests.

> If I would be able to choose convertors I might decide IN VIEW ITSELF 
> that that specific model value should be coloured/pretty 
> printed/rendered according to some specific logic. As long as this logic 
> has read-only access to model and performs steps to produce some 
> rendering I do not find it SoC break.

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.

Joerg

Mime
View raw message