Joerg Heinicke pisze:
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.
Doesn't that tie both CForms and CTemplate together? Imagine using only
one of both - which would break the concept.
My understanding is that this approach ties CForms to EL and CTemplate to EL so
EL functionality becomes a bridge for two way communication.
I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and
its state.
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 an interesting approach. IMO it should always work this way, not
like the above one for stateful form-processing.
Same feelings here. This would make whole processing easier to follow, wouldn't
it?
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.
My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the
certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template.
Spring approach is about attaching everything in advance.
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?
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.
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.
Both are good points. I would be very interested in Daniel's response...
It would be like having id selectors but not class selectors in CSS.
I think this comparison is misleading. IMO path and variant are really
similar concepts. It's only the way where/how they were specified and so
the converter is selected.
I support Daniel's view. You can apply certain variant to several different paths. Actually, the point is that we could treat Daniel's
proposal in Spring terms.
Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from
the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable
converter for each object) and registering more than one converter it's conceptually different from Spring's approach.
I hope that paragraph didn't confuse things even more...
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.
So how far are we from an overall agreement and Grek implementing this
for us ;-)
I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I started to implement Object Model several
days ago without detailed vision and the whole development turned out to be fairly painful because I found hard to design something that
covers so broad subject like universal Object Model usable for whole Cocoon.
I hope it will be easier with converters because all this struggle scared me a
little bit.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
