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:
void setWidgetDefinitionBuilders(Map wdbs) { this.wdbs=wdbs; }
...
this.wdbs.get("form");
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>
And if we find this to painful to write, it is possible to create a
custom XML extension:
<property name="widgetDefinitionBuilders"
selector:inteface="o.a.c.f.f.WidgetDefinitionBuilder"/>
And get away completely from any service selectors. This is similar to
what is done for flattening of sitemap components, isn't it?
Yes.
...
IIRC the SpringServiceSelector could lookup other beans by interfaces,
right?
Yes, see
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/DispatcherServlet.java,
for an example where I lookup all servlets having a mountPath property
in the init method.
Anybody else think this is achievable and make sense?
Absolutely!
/Daniel
