Daniel Fagerstrom wrote:
Vadim Gritsenko skrev:
Giacomo Pati wrote:
CFroms is utilizing lots of Avalon ServiceSelector and this hinders
extensibility of it as adding new Widget types etc. is becomming a
pain with config files in jars.
I've thought about a Spring version of a ServiceSelector to allow a
more flexible configuration and extensibility with a class like
class SpringServiceSelector implements BeanFactoryAware, ServiceSelector
Eww :) Why do you need SpringServiceSelector? IMHO forms should be
just modified to obtain necessary dependencies directly from manager:
manager.lookup("o.a.c.f.f.WidgetDefinitionBuilder/form")
Eww ;) Why do you need lookup? IMHO we should use dependency injection:
Hint: ServiceManager is injected, or it should be.
void setWidgetDefinitionBuilders(Map wdbs) { this.wdbs=wdbs; }
...
this.wdbs.get("form");
Hint: this operation is "map lookup". So you have replaced one lookup from
injected object with another lookup on another injected object. Net result: no
change. :-P
And the map is provided by a factory bean that looks up all beans that
implements an interface and get the selector role from a property:
<property name="widgetDefinitionBuilders">
<bean class="o.a.c...BeansByIntefaceFactoryBean">
<property name="inteface"
value="o.a.c.f.f.WidgetDefinitionBuilder"/>
<property name="roleAttribute" value="role"/>
</bean>
</property>
This is *exactly* what we have now: nested declaration. And this is *exactly*
what causes the problem: there is no way to easily extend standard configuration.
There should be a way to add declarations of new forms component as stand alone
spring beans, and forms should be able to pick them up. I figure we just should
re-use existing machinery used in the sitemap. It certainly beats introduction
of Yet Another Way To Lookup Components.
In short, I'm fine with any mechanism, as long as it is used consistently
throughout Cocoon.
Vadim
