cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Clarification on converter concept
Date Sat, 14 Jul 2007 00:07:13 GMT
On 13.07.2007 10:31, Grzegorz Kossakowski wrote:

>>> 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.
>> Doesn't that tie both CForms and CTemplate together?
> My understanding is that this approach ties CForms to EL and CTemplate 
> to EL so EL functionality becomes a bridge for two way communication.

This is indeed more exact. I considered EL being part of CTemplate :-)

> 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.

FormsTransformer? It has a template approach as well [1], but no EL at all.

Actually I'm not very keen on any templating approach at all. I don't 
like to first provide data to some template context and second retrieve 
it from there in the template. IMO it's much better to have a complete 
push approach and only encroach if it is necessary (like XSLT 
templates). (My diploma thesis was about this btw.) A possible 
implementation for this is to convert the form model into an XML 
representation and let a quite generic XSLT do the rest. With this 
approach no EL come into play. This also means there is a separate 
object-to-string step.

>>> In a stateless scenario, we could instead store the assoications in 
>>> the form page.
>> IMO it should always work this way, not like the above one for
>> stateful form-processing.
> This would make whole processing easier to follow, wouldn't it?

Difference should not be that big since it's more an implementation 
detail than something that should concern the user. My main reasoning 
was the decoupling of EL and CForms.

>> 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.

That's true. It's the controller that decides which converters get 
applied, not the view.

The "minor difference" I talked about was from the registry POV. 
Something is just asking for a converter, the only difference is the 
string which is used for retrieving the converter then.

> 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.

Hmm, not really. Even with the current default implementation you can 
register multiple converters per path differing in the type. You just 
add another criteria. What's different is the more complex understanding 
of "path" since you might include the variant in it. Seems to be only a 
matter of registry implementation how it stores and finds converters.

> I hope that paragraph didn't confuse things even more...

I needed to read it twice but I think I got the message :-)

>> 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 didn't want to put any pressure on you ;-) Just wondered what the open 
issues are we still have.



View raw message