Joerg Heinicke pisze:
Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
I mentioned that snippet as an example how registry could work; my aim was to
show that we use declarative approach instead of registering converters/
property editors manually.
Ah, got it. :-) Though the names are a bit irritating. Aren't the
ExpressionCompilers actually the factories and isn't the ExpressionFactory more
of a registry? It's also a bit strange that the Expressions must be aware of the
prefix they are mapped to (Expression.getLanguage() + constructors of
implementations). Any reason for that?
Good point about names. I'll consider to rename this classes since I don't consider them as any public API (it was used in template block
only to date).
When it comes to prefix and getLanguage() method, I don't know really. Eclipse tells me that this method is not us anywhere in Cocoon so I
think it redundant. Before removing it I'll try to search archives. This stuff is really work in progress and comes as legacy so I don't
know answers for all questions...
Something similar exists for the PropertyEditors, the PropertyEditorRegistrar
[1]. You are only supposed to implement it yourself which more or less means to
add the PropertyEditors programmatically. Since I did not want to do this, I
wrote a MapBasedPropertyEditorRegistrar (matching more or less
DefaultExpressionFactory) which I could at least configure from Spring.
spring-configurator's BeanMap seems to go one step further and searches for all
implementations of a particular interface in the application context.
How your MapBasedPropertyEditorRegistrar knows path at which particular editor
should be registered?
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. :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
