Daniel Fagerstrom pisze:
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.
What about map: language we have discussed earlier? I think it makes sense to
have such a domain-specific, damn simple language. If it takes
ten minutes to learn such a language and it improves readability, I think it
makes to have one. Having bunch of general ELs is what I want
to avoid too.
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.
That's a really neat idea! I have not thought about it that way and I really
like it! :-)
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.
Getting back to the earth, are you sure that all browsers will be happy with #
character in field's name?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
