cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Clarification on converter concept
Date Wed, 11 Jul 2007 23:18:18 GMT
On 10.07.2007 10:30, Grzegorz Kossakowski wrote:

>>> What do you mean by registering?
>>
>> Where does the template know from which converter to apply? That's
>> defined by a particular converter which can be looked up by the
>> template in the registry.
> 
> It will be bean's ID pointing that this particular bean implements 
> "short" variant. We use powerful Spring configurator[1] stuff for doing 
> the trick, see this[2] for an example:
>   <bean id="org.apache.cocoon.components.expression.ExpressionFactory"
>         
> class="org.apache.cocoon.components.expression.DefaultExpressionFactory">
>     <property name="expressionCompilers">
>       <configurator:bean-map 
> type="org.apache.cocoon.components.expression.ExpressionCompiler"/>
>     </property>
>   </bean>
> 
> The expressionCompilers property is a Map.
> 
> Yes, there is still a registry but neither EL user nor EL implementation 
> must care about it.

This looks like a registry for expression languages, not for converters. 
How is it related?

> Could you elaborate on the "impedance mismatch"? I would like to see
> concrete examples to know what you mean. I'm curious because I used to
> really like JXPath.

I stole this term from O2R mapping where it is known that there is no 
1:1-mapping between the concepts. I remember having a similar problem 
with working with XPath on objects, especially collections. I thought 
this was even documented in the official documentation [1] but I can't 
find it from a quick look. So drop this.

> Now I get your point, and understand your arguments. However, as we seen 
> already Daniel proposed very neat solution.

Let's continue this discussion on the other branch of this thread.

> As for now I much prefer such solution because playing with registries 
> keeping PropertyEditors attached to some paths is not the most elegant 
> solution, IMHO.

Can you please elaborate on this and add it to this other branch why 
actually? Maybe there is a different understanding which lead to 
different impressions on this.

> This mail helped a lot not only to understand your stand but to bring 
> issues that I have not been thinking about before.

Good to hear :-)

Joerg

[1] http://jakarta.apache.org/commons/jxpath/users-guide.html

Mime
View raw message