cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Springifying CForms: How to solve LifecycleHelper stuff
Date Mon, 17 Sep 2007 14:12:33 GMT
Hash: SHA1

Daniel Fagerstrom wrote:
> Giacomo Pati skrev:
>> Giacomo Pati wrote:
>>> Hi all
>>> If there is nobody working on the subject I'll spend a few hours on
>>> doing that.
>>> My general tactic would be to first rewrite the xconf/rules into a
>>> spring config so that adding new
>>> Widgets/Converters/Datatypes will than be easily manageable (using
>>> bean-maps) and than see how the
>>> classes have to be rewritten to follow that.
>>> Any better ideas?
>> Now that I'm trying to do it I have some qustions about how we can
>> manage LifecycleHelper stuff in
>> a Spring context.
>> In CForm definition files there are constructs that accepted a class
>> attribute to denote a Java
>> class being instantiated and managed as it where a Avalon Component
>> (Validators, SelectionLists,
>> and more). Whats the oppinion of other on this subject.
> Deprecate it. It should be enough to define beans in the Spring
> container and refer to them in the form definition.

Again, how should deprecation be implemented:

a) use deprecation logger but keep current implementation
b) throw an exception and remove current implementation

> What I also would like to see, but it might be outside you current
> scope, is to get rid of the selectors. I would prefer a solution where
> maps with widgets, data types and so on are created with the bean-map
> and these maps are injected into the form manager.

This is absolutely in my scope. I don't want to see those Avalon ServiceSelector again ;-)

- --
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -

Version: GnuPG v2.0.6 (GNU/Linux)


View raw message