cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Fri, 05 Nov 2004 10:19:47 GMT
Daniel Fagerstrom wrote:
>> What that means is that a convertor should be able to do the following 
>> conversions:
>> - string+locale --> object : parsing request parameters
>> - object+locale --> string : producing the value of an input
>> - object+locale+channel --> xml fragment : producing the output view 
>> for a particular channel (html, wap, fo, etc).
>> WDYT?
> Interesting idea! Question is how do we now that a negative number is a 
> financial entity rather than a temperature, e.g. In the renderer we only 
> know the type of the object to render. Of course if we use more fine 
> grained data types like FinancialNumber and Temperature it would be 
> feasible. But wouldn't that be to let view concerns slip into the model?
Shouldn't user be able to choose a convertor?

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

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 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 
- build another object graph only for the sake of one view
and above all:
- change my model every time I change view template

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?

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.

Leszek Gawron                            
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message