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: <418B79CA.9000805@nada.kth.se>
Date: Fri, 05 Nov 2004 14:02:02 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
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>
In-Reply-To: <418B53C3.9020000@mobilebox.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Leszek Gawron wrote:

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


Have not thought about it, but it sounds like a good idea. My idea was 
mainly about convertor sets, so that you have a list of object+locale 
--> string mappings in a convertor configuration file. When you 
configure your JXTG (or some or some other template engine), you choose 
a default convertor set that is automatically used for all object 
accesses. Then you also can configure a set of alternative convertor 
sets that you can choose between by explicitly asking for a convertor 
set. Using the synatax you propsed earlier: ${elEngine:path} would give 
the default convertor set and ${convertorSet:elEngine:path} would give a 
named convertor set.

But it might be a good idea to give more fine grained control.

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


I agree, that was also what I said in the rest of my mail.

> 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 database
> - 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?


Of course it should. The interesting question is of course how to 
achieve that. Needing to write specialized adapters for the model data 
to make it suitable for the view layer is not such a good idea. Large 
amount of type checking code in the view is not a good idea either.

I'll send a link to our discussion to Terence Parr and asks if he would 
like to join the discussion.

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


Seem like an excelent idea to me. I think it could be analog to the use 
of the class attribute in HTML to give hints to CSS about styling.

We could have something like:

  ${month/balance?class=financialValue}

then the finacialValue rule for convertion is used if there is one 
otherwise the default rule is used. There is no doubt room for 
improvement of the syntax ;)

A functional syntax as Sylvain prpoposed would also be possible:

  ${convert(month/balance, 'financialValue')}

but I percieve the convertor as something that not is part of the 
expression language (EL). The convertor is applied to the object that is 
returned from the EL engine, and the default convertor should always be 
applied on the object, so one shoudn't need to write

  ${convert(month/balance)}

to get the default conversion.

WDYT?

/Daniel