cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
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.

/Daniel


Mime
View raw message