cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Clarification on converter concept
Date Sat, 14 Jul 2007 19:55:22 GMT
Joerg Heinicke skrev:
> On 07.07.2007 11:16, Daniel Fagerstrom wrote:
>> 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.

What I meant is that the property path is of course the same for both 
read and write access, but its representation is different in CForms for 
the both cases. For reading it is doesn't have any explicit form but is 
only implicitly represented in the tag structure for a CForm. For write 
access it has the mentioned (e.g. "tasks.2.startDate") form in the name 
attribute of the generated html form tag.

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

The main difference in my view is that with paths the choice of 
presentation is connected to the model and with anchors it is connected 
to the presentation.

Both cases have legitimate uses. A particular date could be presented 
both in its short form in a table and in its long form in a text. That 
is clearly a presentation issue.

A specific double in a model should normally not represent both a 
percentage, a currency amount and a scientific value, what it represents 
is clearly a model issue. And we are probably only having one 
presentation for each representation, so the path idea is better in this 

 From a OO purist POV, there should be own classes for currency amounts, 
percentages and so on, so we wouldn't have to care about variant 
representations at all in this case. But as Java isn't a pure OO 
language, such a purist view isn't practically feasible, we need 
variants in this case as well.

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

It is up to the user. The user could as an example have a "short" 
variant for the short form of a couple of different data types.

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

In the date case where there are several different presentations of the 
same concept it is part of the presentation concern and shouldn't be 
separated from 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.

That is an implementation detail. We have an object model that an 
expression language can be applied on where the result in turn can be 
converted by a converter and the result in turn can be used in a 
template. We have 4 different parts that can be used both together and 
in parts if implemented in the right way.

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

That is an important thing that we would lose. As described above we 
would lose the ability to chose between different presentations in the 
view. Further, using an EL and format variants on a bean model would 
probably be possible for a web designer. Writing Spring bean 
configurations seem to be a little bit to much.

Also if you have e.g. a regexp defined format, will you need to repeat 
it for each property path you would like to apply it on?

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

Class selectors in CSS was the inspiration for the variants.

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

To me this sounds like Spring doesn't have a satisfying solution to the 
locale problem right now.

PropertyEditors and BeanWrapper could be usable, but the registry 
architecture in Spring just don't help us currently.


View raw message