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
