cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Clarification on converter concept
Date Sat, 07 Jul 2007 15:16:46 GMT
Joerg Heinicke skrev:
> On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
...
>>> I always found the JEXL/JXPath syntax rather counterintuitive.
>>
>> What was counter-intuitive apart from switching between both that I do 
>> not like either?
> 
> The ${} and #{}, the impedance mismatch between objects and xml model: 
> JXPath on beans does not behave like on xml.
> 
>> How Spring syntax looks like and how it is better than JXPath/JEXL?
> 
> Bean property syntax which as used in other template languages like 
> Velocity and scripting languages as well: object1.object2.property.

Just to clarify: I would much have preferred if we only had one 
expression language (EL) in Cocoon and a property style syntax like the 
Spring one or JEXL would be fine with me.

But as ELs are used everywhere in Cocoon webapps, most users have a 
heavy investment in the current set of ELs. So we just cannot deprecate 
them and require all the users to rewrite all their webapps to the new 
"better" EL at one go. We need a mechanism that simplify for new users 
and new webapps by making it easy to use one default EL everywhere at 
the same time that we don't require users to rewrite their old webapps.

This is the main motivation for the plugable EL architecture.

...
> On 05.07.2007 14:24, Daniel Fagerstrom wrote:
...
>> Converter Registry
>> ----------
> 
>> For a Cocoon framework I would prefer looking up a converter based on
>> class, locale and variant, while I don't see any obvious use cases for
>> property path.
> 
> Indeed the PropertyEditorRegistry seems not to meet our requirements.
> 
> (copied from further above, better fits in here)
>> The framework select based on data type and locale. But for e.g. dates
>> there are several different string representations (short, medium, full
>> and long or maybe some custom format) that the template or form author
>> needs to choose between. To me it seem reasonable to have a syntax for
>> making this possible in e.g. the template.
> 
> As I wrote repeatedly the possibility to influence the formatting from 
> the template breaks the two-way process. You can't parse a date 
> expecting a FULL pattern string when receiving a string formatted with 
> SHORT pattern. And there is no chance to get informed about this mismatch.

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. Consider a form template, where you have various widgets:

<ft:widget id="startDate">
   <fi:styling type="short"/>
<ft:widget/>

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. The name attribute is then 
used by the browser when posting the filled in value of the form 
element. In the case of nested widgets, the property path is created 
from all the ids of the parent widget as well, so we can have property 
paths like tasks.2.startDate, if the start date is part of a task list, e.g.

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

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.

So as you can see it is possible to put the choice of formatting variant 
in the form template so that the two-way aspect is respected.

> 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. But 
as we saw choosing format variant in format templates is possible.

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.

>> So as a conclusion: it would be nice to reuse the Spring stuff and
>> there are big overlaps, but especially for locale handling it is not
>> obvious to me how to use it. Then of course there is the question if
>> it is worthwhile to reuse.
> 
> The concepts seem to be totally equal. We only extend the registry with 
> the locale. Then I mentioned a new way of registering PropertyEditors, 
> the PropertyEditorRegistrar. That's actually a PropertyEditor factory 
> which also does the registering shown above when talking about the 
> initBinder() method. It is possible to set up such a registrar once (!) 
> in the application context and reuse it in the application context 
> itself (e.g. for custom data types) or in the controllers. The point I 
> want to make is the following: This PropertyEditorRegistrar is in 
> contrary to initBinder() not even request-aware and so not locale-aware 
> at all. So I wonder how it is supposed to be done in Spring now. Maybe 
> filing an issue for an extension of the registry brings this into 2.1 
> and we do not have to invent anything new. And even if not there is 
> still so much to reuse and it's IMO absolutely worthwile to do it.

I'm not able to parse the above paragraph. 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?

> I hope, I did not write too much non-sense in my hurry. Have to get to 
> the plane to the US (finally!) soon. Maybe I could even clarify a bit of 
> the confusion I caused with the last mail. :-)

You clarified a lot.

/Daniel

Mime
View raw message