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 Sat, 14 Jul 2007 03:05:56 GMT
On 13.07.2007 17:06, Grzegorz Kossakowski wrote:

> How your MapBasedPropertyEditorRegistrar knows path at which particular 
> editor should be registered?

Hmm, that's indeed getting a problem. Not with the 
MapBasedPropertyEditorRegistrar itself, it handles nested maps. The key 
of the first map is the data type, the key of the second one the path. 
This needs to get flattened on 
PropertyEditorRegistrar.registerCustomEditors(PropertyEditorRegistry) to 
match PropertyEditorRegistry.registerCustomEditor(Class type, String 
path, PropertyEditor editor).

<bean class="MapBasedPropertyEditorRegistrar">
   <constructor-arg index="0">
     <map key-type="java.lang.Class">
       <entry key="MyDataType" value="MyDataTypeEditor"/>
       <entry key="MyOtherDataType">
         <map>
           <entry value="defaultMyOtherDataTypeEditor">
             <key><null/></key>
           </entry>
           <entry key="object.property"
                  value="specialMyOtherDataTypeEditor"/>
         </map>
       </entry>
     </map>
   </constructor-arg>
</bean>

It now gets a problem since there seems to be no obvious way to 
automatically register editors with path - except some more complex way 
of (mis)using the bean's name. Hmm, what about (adapting the EL registry 
way):

<bean name="MyDataTypeEditor/path#variant"
       class="MyDataTypeEditor"/>

with both path and variant being optional. This still lacks the 
registering for our third criteria, the locale. So I wonder if we don't 
need a different style of registering anyway.

> Spring configurator stuff is really handy and has no Cocoon dependencies 
> so its wise to use it. Joerg, you seem to sit inside Spring community, 
> have you considered giving Carsten a present by promoting his stuff? I 
> really think it should get more attention. :-)

Hmm, was the first time I had a look into it today. I can't say if this 
all is of general use. Do you think of moving this stuff or parts of it 
to Spring (that would be actually up to Carsten IMO) or just get more 
users to it? For the latter it would be good to have documented what's 
there and how it is supposed to be used. The documentation at Daisy is a 
bit spare.

Joerg

Mime
View raw message