cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Springifying CForms
Date Wed, 26 Sep 2007 13:59:19 GMT
-----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-----

Mime
View raw message