cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Clarification on converter concept
Date Fri, 13 Jul 2007 14:31:06 GMT
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

View raw message