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

Reply via email to