Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of joerg.heinicke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <46954DEE.8040401@gmx.de>
Date: Wed, 11 Jul 2007 17:38:54 -0400
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Clarification on converter concept
References: <468AA7E9.7020902@tuffmail.com> <468AC988.60809@gmx.de>
 <468C2397.9060105@apache.org> <468F2540.2070109@gmx.de>
 <468FAE5E.6060509@nada.kth.se>
In-Reply-To: <468FAE5E.6060509@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

On 07.07.2007 11:16, Daniel Fagerstrom wrote:

>> As I wrote repeatedly the possibility to influence the formatting from 
>> the template breaks the two-way process.
> 
> First, from a separation of concern POV, it is IMO much preferable to 
> influence the formating variant, both for output and input, in the form 
> template.
> 
> Second, we have the question if it is possible to accomplish ;) Yes, I 
> think it is.
> 
> The form infrastructure creates two property paths from the id. One for 
> accessing the start date from the form object to insert in the generated 
> html page. And one property path is used as content of the name 
> attribute in the generated html form element.

Can't quite follow. Isn't that supposed to be the same one? I mean when 
the path is used as form field's name it ends as request parameter name. 
That one needs to be used to bind the value to the form object correctly.

> So from the above we see that the form template actually create the 
> property path that is used both for getting and setting the property in 
> the form model that the widget is connected to.

Yes, clear so far. Spring MVC does it very similar btw.

> From this we are not that far away from connecting formatting variant
> to the property path.
> 
> In a state full scenario we are keeping the form object in e.g. a 
> session, so the form template generator could store the associations 
> between property paths and formating variants in the form object as 
> well. These associations are then available to use when parsing the 
> input from the post. And we can make sure that the right variant of the 
> converter is used.

Doesn't that tie both CForms and CTemplate together? Imagine using only 
one of both - which would break the concept.

> In a stateless scenario, we could instead store the assoications in the 
> form page. We could e.g. add it to the property path in the name 
> attribute: "tasks.2.startDate#short". Then the post parser can use the 
> variant info for choosing the right converter.

That's an interesting approach. IMO it should always work this way, not 
like the above one for stateful form-processing.

And actually we are back to the Spring way using the path, aren't we? 
There is only the minor difference of using the full path vs. the 
anchor. The anchor adds additional flexibility since it can be specified 
in contrary to the generated path.

I only really don't know if that flexibility is good. I mean you talked 
about scattered locale handling. This solution now tends to scattered 
variant handling IMO. I also don't know how it conforms with Parr's 
requirements for a template language. Doesn't this variant selection go 
very much into the direction of assumption about the data type?

I can live with this concept but actually I prefer the path stuff of 
Spring much more since this is completely transparent to the template. 
It also completely decouples the object-to-string conversion from the 
templating while with the "select a variant"-approach in the template 
the conversion can not be done without the template.

The question is what we lose when refraining from the variant: Only the 
possibility to use one property of the object twice in a template and 
format it differently. Anything else is addressed in Spring. So you can 
register form-specific converters. That's also how I handle it when I 
register converters for a particular path. In contrary type-specific 
converters are registered globally. (Where "globally" is not quite 
correct since the converters are prototypes anyway. The registration is 
a topic on its own below.)

>> The property path could be used to determine the variant instead of 
>> specifying it explicitly. It's obviously not that flexible - but can't 
>> be broken in that way. That's why I would opt for class, locale and 
>> path, so add locale to Spring's PropertyEditorRegistry methods.
> 
> It would be like having id selectors but not class selectors in CSS.

I think this comparison is misleading. IMO path and variant are really 
similar concepts. It's only the way where/how they were specified and so 
the converter is selected.

> As we need handling of ELs, we could use "property paths" that includes 
> the format variant e.g. "foo.bar#short" or even just "#short". The later 
> for applying the beanEditor when the "short" variant is asked for.

Yes, a combination of both (very similar) concepts seems to be possible 
easily.

> Do you mean that you agree about that it is unclear how to handle
> locals with the bean wrapper stuff? Or are you starting to see some
> solution?

Both actually. I try to rephrase the confusing paragraph ...

There is indeed no way to select a converter based on the locale at the 
moment. What you can do though is to register a locale-specific 
converter based on the request information (remember the initBinder() in 
my last mail). But this approach is really awkward since you need to do 
this in every controller you write. That's why I wrote "So you might 
drop that complete section from mind :-)".

The new approach using PropertyEditorRegistrar externalizes this into 
another component. But that one has no access to the request information 
and so can not even create locale-specific converters. What I know asked 
myself: How I am supposed to do this at all with Spring? I will file an 
issue at Spring's Jira requesting an improvement about a locale-aware 
registry. My hope is that this might get fixed for Spring 2.1 since I 
consider this really important and generic enough to be of use in Spring 
in general. Then we do not even need to modify/ replace this part of 
Spring's converter infrastructure.

Otherwise I would reuse as much as possible of this infrastructure 
though. It's only the registry part that needs modification/ 
replacement. Therefore dropping the complete infrastructure does not 
make much sense IMO.

So how far are we from an overall agreement and Grek implementing this 
for us ;-)

Regards,
Joerg