-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Giacomo Pati wrote: > Hi all > > If there is nobody working on the subject I'll spend a few hours on doing > that. I'm done with it :-) but need an advice on a special case: There are some special 'custom' stuff which had been referenced in form definitions/bindings by the mentioned 'class' attribute which is now replaced by a 'ref' attribute and must be a Spring bean. Those classes were handled by LifecycleHelper as Avalon Components (which I've eliminated in that block). Those custom classes could have implemented the Avalon Configurable interface to get access to the XML snippet in the definition/binding file as a Avalon Configuration object. So how should that be handled now as they are all managed by Spring? I have 2 possibilities: a) check the custom class/bean whether it has a 'setConfiguration' method by reflection and pass the DOM snipped to it b) extend the base interfaces (WidgetValidator, etc) to a ie. ConfigurableWidgetValidator, etc.) that has that setConfiguration method to pass the DOM snipped to. So, a) could be said being black magic, and b) could be said being overdesigned. So I'd like you guys give your oppinions so that I can polish that last thing up and commit. BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have a new version for the sprinigied blocks? Ciao and TIA - -- 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) iD8DBQFG+mW3LNdJvZjjVZARAk3BAKDqaKJ8GxzvBCIi9DedQnm8JKyx+ACeKJU7 kY17g6yZTMwAK6YPX3GbE7c= =GwWB -----END PGP SIGNATURE-----
