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 ;-)
Great!
/Daniel
