Giacomo Pati wrote:
Giacomo Pati wrote:
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.
As Felix was the only one giving oppinion about stuff above, I'll implement b)
which leads to 2 new
interfaces ATM to conform semantically to Avalonian CForm version:
My favorite is also b)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
