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