cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Springifying CForms: How to solve LifecycleHelper stuff
Date Mon, 17 Sep 2007 13:59:27 GMT
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.

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.


View raw message