cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Fri, 05 Nov 2004 09:57:39 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:


>> In the (often cited on this list) article: Enforcing Strict Model 
>> View Separation in Template Engines, by Terence Parr 
>>, a number of 
>> rules for strict separation between model and view are given. One of 
>> them is that the view shouldn't make any assumptions about data types 
>> of the model data. The view should only get displayable strings.
> I don't agree with this rule as, in order to avoid the view to know 
> about the model, it requires the model to know about the view. IMO, 
> the view should be given the necessary pointers to access the model 
> data it needs. The granularity of these pointers is the key point that 
> has to be chosen wisely.

I'm not certain that I agree with his rules either. I'm always looking 
for better ways to better ways to separate content from view (and 
finding god SoC in general in my apps). It is far to easy to write 
"write only" code, code that felt natural when you wrote it, but is hard 
to understand when you get back to it a couple of months later. I found 
Terence Parr's article interesting and inspiring and trying to see if we 
can apply these ideas in Cocoon webapps.

I also think that we as a community must work hard to not let to much 
Java slip into the view aspects of Cocoon. It happens very easy as most 
of us at cocoon-dev are Java programmers. So a first reaction is often 
that; I want the full power of Java (or at least programming), in my 
view, in my form handling, in my controller and everywhere. But as soon 
we let do that, we makes it much harder to enforce SoC and we makes it 
very hard for non-programmers to be part of our webapp development projects.

Terence Parr says about templates: "If it looks like a program, it 
probably is."

> Your convertor proposal below can be a good way for the controller not 
> to know too much about the view needs and for the view not to depend 
> too much on the implementation details of the model.

Yes, it would at least take away some irritating rendering code from the 
view or from the model. Enforcing strict model view separation in 
Terence Parr's terminology is not probably not possible as long as we 
use powerfull expression engines like JXPath or JEXL, I'm not, (yet at 
least), certain that I would find it desirable either.


>> I think the renderer component idea could give a better SoC in CForms 
>> as well. I have had a feeling that data type convertion is not a 
>> natural part of the model (form definition) for a while. A problem is 
>> that conversion configuration must be repeated each time the data 
>> type is used.
> The repeated configuration is a problem that will be solved once we 
> have the ability to define widget types and repositories [1].

Yes, that problem would disappear. Still a converter/renderer step, 
IMHO, would give a nicer SoC, see my reply to Jonas for details. Also a 
converter/renderer component with default configiruation files, would be 
usable for rendering of non cforms data also.

A related question: will the widget types still contain label 
information, or will the label info be a concern for the template instead?


>> So, the basic idea is to factor out the type conversion 
>> functionallity from CForms and make it available for all rendering 
>> and input handling needs in Cocoon.
> This is an interesting idea, which could be even more useful if the 
> convertors were able not only to produce strings, but also XML 
> snippets for output-only data. For example, we may want an email 
> address to be rendered as a <a href="mailto.."> or negative numbers 
> being displayed in red, or enclosed in parenthesis.
> 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).

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?

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

I found that a little bit fundementalistic and still prefer to have it 
in the view:

<jx:when test="$value&lt;0">
<span class="loss">{$value}</span>
<span class="winn">{$value}</span>

preferably put in a template so that I don't have to see it more than once.

Here we obviously let data types slip into the view. Reconnecting to the 
previous discussion with Jonas about data types accesible in the view, 
this would mean that boolean are needed also. In a test attribute the 
template engine asks for a boolean. In a forEach an iterator is asked 
for and when a value is needed this will be pased thrue the rendering 
step to create a string or possibly an XML snippet. So the renderer 
still simplifies things, but we don't have any "strict separation"

I would prefer to have stricter separation than that, any ideas about 
how to achieve that?


View raw message