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 14:27:42 GMT
Giacomo Pati skrev:
> 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
a) is probably the correct solution, but at least I would prefer b). To 
me, the class attribute in forms for creating components seem like some 
hack or workaround that hopefully very few depends on.

>> 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


View raw message