-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 > 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 ;-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG7otRLNdJvZjjVZARAilDAJ9tKF49BH+Q8AXrOpy7d1U09ZguPwCgtRYQ cM974YYtkLL2vbMna0j7g80= =3/SP -----END PGP SIGNATURE-----
