You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2007/01/23 10:08:28 UTC
Sprinifying CForms
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all
I'm thinking about springifying CForms and want to check about
oppinions.
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
Which uses the BeanFactory to fullfill the contracts of the
ServiceSelector and thus flattens the configuration from having
components inside a ServiceSelector config as whith Avalon to all beans
at the same level and thus extensibility is for free than.
I was thinking of going from Avalon config
<forms-formmanager logger="forms.model">
<widgets>
<widget name="form" src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/>
.....
</widgets>
</forms-formmanager>
to Spring config
<bean id="ServiceSelector/forms-formmanager"
class="SpringServiceSelector">
<property name="role" value="o.a.c.f.f.WidgetDefinitionBuilder"
</bean>
<bean id="o.a.c.f.f.WidgetDefinitionBuilder/form">
class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
...
</bean>
IIRC the SpringServiceSelector could lookup other beans by interfaces,
right?
Anybody else think this is achievable and make sense?
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.1 (GNU/Linux)
iD8DBQFFtdCOLNdJvZjjVZARAgb5AJ9+umep3uBCgpYhq73ieZj5lo0KBACbBDtx
F8P8bRcZ3/rc4L9vXZoF1aQ=
=76mb
-----END PGP SIGNATURE-----
Re: Sprinifying CForms
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 23, 2007, at 6:54 AM, Ralph Goers wrote:
> How will you make this compatibile with 2.1.x? The code base is
> shared.
Is it time to make it not shared anymore?
—ml—
Re: Sprinifying CForms
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 23 Jan 2007, Ralph Goers wrote:
> Date: Tue, 23 Jan 2007 06:54:31 -0800
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org, rgoers@apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Sprinifying CForms
>
> How will you make this compatibile with 2.1.x? The code base is shared.
Good point. Is it still shared?
IIRC 2.1.10 (or 2.1.11) will be the last 2.1.x series release (or did I
miss something)?
By a copy to a form-spring module (or so).
>
> Giacomo Pati wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all
>>
>> I'm thinking about springifying CForms and want to check about oppinions.
>>
>> 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
>>
>> Which uses the BeanFactory to fullfill the contracts of the
>> ServiceSelector and thus flattens the configuration from having components
>> inside a ServiceSelector config as whith Avalon to all beans at the same
>> level and thus extensibility is for free than.
>>
>> I was thinking of going from Avalon config
>>
>> <forms-formmanager logger="forms.model">
>> <widgets>
>> <widget name="form"
>> src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/>
>> .....
>> </widgets>
>> </forms-formmanager>
>>
>> to Spring config
>>
>> <bean id="ServiceSelector/forms-formmanager"
>> class="SpringServiceSelector">
>> <property name="role" value="o.a.c.f.f.WidgetDefinitionBuilder"
>> </bean>
>> <bean id="o.a.c.f.f.WidgetDefinitionBuilder/form">
>> class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
>> ...
>> </bean>
>>
>> IIRC the SpringServiceSelector could lookup other beans by interfaces,
>> right?
>>
>> Anybody else think this is achievable and make sense?
>>
>> Ciao
>>
>> - -- Giacomo Pati
>> Otego AG, Switzerland - http://www.otego.com
>> Orixo, the XML business alliance - http://www.orixo.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.1 (GNU/Linux)
>>
>> iD8DBQFFtdCOLNdJvZjjVZARAgb5AJ9+umep3uBCgpYhq73ieZj5lo0KBACbBDtx
>> F8P8bRcZ3/rc4L9vXZoF1aQ=
>> =76mb
>> -----END PGP SIGNATURE-----
>
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.1 (GNU/Linux)
iD8DBQFFtixhLNdJvZjjVZARAqDfAKCvBurjkQ5nGFr+X3c33rOiYSR2fQCfbwVc
07xRY2aS3T5p7UeQ+LxlRpg=
=huNw
-----END PGP SIGNATURE-----
Re: Sprinifying CForms
Posted by Ralph Goers <Ra...@dslextreme.com>.
How will you make this compatibile with 2.1.x? The code base is shared.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all
>
> I'm thinking about springifying CForms and want to check about oppinions.
>
> 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
>
> Which uses the BeanFactory to fullfill the contracts of the
> ServiceSelector and thus flattens the configuration from having
> components inside a ServiceSelector config as whith Avalon to all
> beans at the same level and thus extensibility is for free than.
>
> I was thinking of going from Avalon config
>
> <forms-formmanager logger="forms.model">
> <widgets>
> <widget name="form"
> src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/>
> .....
> </widgets>
> </forms-formmanager>
>
> to Spring config
>
> <bean id="ServiceSelector/forms-formmanager"
> class="SpringServiceSelector">
> <property name="role" value="o.a.c.f.f.WidgetDefinitionBuilder"
> </bean>
> <bean id="o.a.c.f.f.WidgetDefinitionBuilder/form">
> class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
> ...
> </bean>
>
> IIRC the SpringServiceSelector could lookup other beans by interfaces,
> right?
>
> Anybody else think this is achievable and make sense?
>
> Ciao
>
> - -- Giacomo Pati
> Otego AG, Switzerland - http://www.otego.com
> Orixo, the XML business alliance - http://www.orixo.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.1 (GNU/Linux)
>
> iD8DBQFFtdCOLNdJvZjjVZARAgb5AJ9+umep3uBCgpYhq73ieZj5lo0KBACbBDtx
> F8P8bRcZ3/rc4L9vXZoF1aQ=
> =76mb
> -----END PGP SIGNATURE-----
Re: Sprinifying CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko skrev:
> Daniel Fagerstrom wrote:
>> Vadim Gritsenko skrev:
>>> Daniel Fagerstrom wrote:
...
>> 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.
It is verbose, but using the xml extension mechanism in Spring 2.0 we
could create a shorter notation as e.g.:
<bean id="o.a.c.f.f.WidgetDefinitionBuilder/form"
class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
<property name="type" value="form"/>
<property name="widgetValidatorBuilders"
selector:interface="o.a.c.f.f.WidgetValidatorBuilder"/>
...
</bean>
Or even shorter by parsing the bean id for "/form", don't think it is
such a good idea to parse ids though.
/Daniel
Re: Sprinifying CForms
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.
Indeed.
> 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
mechanism.
Vadim
Re: Sprinifying CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko skrev:
> 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.
BeanFactoryAware was mentioned above. But of course can the
ServiceManager be injected.
>> 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.
>> 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.
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. And yes, that is achievable by using the
BeanFactoryUtil.beansOfTypeIncludingAncestor
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/BeanFactoryUtils.html.
/Daniel
Re: Sprinifying CForms
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: Sprinifying CForms
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Sprinifying CForms
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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")
And get away completely from any service selectors. This is similar to what is
done for flattening of sitemap components, isn't it?
> Which uses the BeanFactory to fullfill the contracts of the
> ServiceSelector and thus flattens the configuration from having
> components inside a ServiceSelector config as whith Avalon to all beans
> at the same level and thus extensibility is for free than.
>
> I was thinking of going from Avalon config
>
> <forms-formmanager logger="forms.model">
> <widgets>
> <widget name="form"
> src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/>
> .....
> </widgets>
> </forms-formmanager>
>
> to Spring config
>
> <bean id="ServiceSelector/forms-formmanager"
> class="SpringServiceSelector">
> <property name="role" value="o.a.c.f.f.WidgetDefinitionBuilder"
> </bean>
Don't like this...
> <bean id="o.a.c.f.f.WidgetDefinitionBuilder/form">
> class="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder">
> ...
> </bean>
But completely agree with this.
Vadim
> IIRC the SpringServiceSelector could lookup other beans by interfaces,
> right?
>
> Anybody else think this is achievable and make sense?
>
> Ciao