cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Sprinifying CForms
Date Thu, 25 Jan 2007 13:32:53 GMT
Daniel Fagerstrom wrote:
> Vadim Gritsenko skrev:
>> Daniel Fagerstrom wrote:
>>>   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
> The important change is that Map not is container specific. You can use 
> the component by just filling a map and testing it. No container 
> dependency.


> But thinking further on it, it doesn't matter that much in the 
> particular scenario of forms. It is only the various builder and manager 
> classes that use selectors. And they are not useful by them self anyway. 
> So DI and avoiding container dependencies makes much more sense for the 
> widgets than for the builder infra structure.

Well but, generally speaking, if you have container (especially dependency on 
specific container implementation - like spring web context - instead of 
dependency on base interface) and/or servlet API dependencies, it makes that 
much harder writing JUnit tests.

>>> 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.
> I guess my description was to terse. What I tried to describe is an 
> adaption of the whiteboard pattern from OSGi, that is used precisely for 
> allowing pluggable extensions.
> The BeanByIntefaceFactoryBean above is not a nested dependency at all. 
> It is a factory bean that searches for all components in the container 
> that implements a certain interface. For each such component it looks up 
> the value of a property and then create a map that contains associations 
> between  property values and the components.
> A more complete example would be that we define a number of components, 
> that could be spread out in many independent blocks:
> <bean id="o.a.c.f.validation.WidgetValidatorBuilderSelector/length"
>      class="o.a.c.f.validation.impl.LengthValidatorBuilder">
>  <property name="type" value="length"/>
> </bean>
> <bean id="o.a.c.f.validation.WidgetValidatorBuilderSelector/range"
>      class="o.a.c.f.validation.impl.RangeValidatorBuilder">
>  <property name="type" value="range"/>
> </bean>
> ...
> Then we have components like that use the widget components that 
> currently depends on selectors, they could be configured like this:
> <bean id="o.a.c.f.f.WidgetDefinitionBuilder/form"
>      class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
>  <property name="type" value="form"/>
>  <property name="widgetValidatorBuilders">
>    <bean class="o.a.c...BeansByIntefaceFactoryBean">
>      <property name="inteface"
>                value="o.a.c.f.f.WidgetValidatorBuilder"/>
>    </bean>
>  </property>
>  ...
> </bean>
> Where the BeanByIntefaceFactoryBean looks up the beans fulfilling a 
> certain interface as described above.

It is rather verbose, but yes, it does solve the problem.

> But, again, in this particular case it is probably not worthwhile to 
> strive for complete DI. Implementing a Spring selector as Giacomo 
> described in the original mail is probably the simplest way to create 
> extendability.

My only concern - please use same lookup method consistently. Both sitemap 
looking up generators/etc and forms manager looking up widgets should use same 


View raw message