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
