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
case.
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. "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.
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.
/Daniel
