Paulo Gaspar wrote:
>
> > For ant it makes perfect sense to have such a way of configuring things
> > (i.e. fully inerted, a-la javabeans). But for more general frameworks, I
> > disagree since, just like for beans, this forces you to have flat
> > configuration files or very complex data2method mapping schemes.
>
> I have to disagree with you on this one.
Sorry for the delay but this has not exactly the best week in my life :/
> My framework is a bit more generic than Cocoon, I implemented such
> configuration mechanism and it is neither flat neither are the mapping
> schemes complex. It sure pays the short time it took to develop.
ok
> What the framework does is out of topic, but the configuration mechanism
> is based on a heavily modified version of Avalon and on several very
> interesting ideas from "myrmidon" - an Ant proposal by Peter Donald.
>
> I am going to talk a bit about it just to transmit my experience that
> "it is not complex" and to give you the same starting points I had.
great, I've seen "myrmidon" and saw that was based on many avalon
concepts (which made *me* very happy but others on the Ant list very
angry) but didn't dive into the new ideas.
> For me, the most interesting concepts in Peter's project are the
> Converter, at:
> org.apache.myrmidon.converter.Converter
> and the Configurer (which I renamed Configurator) at:
> org.apache.myrmidon.interfaces.configurer.Configurer
>
> This proposal is in the Ant CVS repository (jakarta-ant) with its source
> is rooted at "/proposal/myrmidon/src/java". Try taking a look at it is
> you have any trouble with the rest of my description (which is a mess).
>
> The Converter (which I modified by dropping the use of a Context) is a
> very generic data conversion mechanism. My implementation differs from
> Peter's and I implemented more mappings, but the idea is just the same.
>
> I developed it quite a bit and I use it together with a Record object
> (basically a typed Map that in some implementations introspects and
> wraps other objects) to make data flow across objects that store named
> data. Example of such data flows: from an Avalon Parameters object or
> from Servlet parameters into a bean, a Map or a JDBC ResultSet. You can
> also consider all possible permutations between objects of this and
> other types.
>
> After having such mechanisms in place, my configuration mechanism (which
> implementation is completely different from Peter's) just took an extra
> 1200 lines of code. And I am including things like introspection and the
> alternative use of both standard java beans and java objects with public
> fields. (I am, however, not including the Converter.)
>
> Without such mechanisms it could take a bit more, but notice that you
> have a lot of starting code at ant-myrmidon. Even if this code (last
> time I looked) does not cache introspection data, that was the easiest
> part of my implementation.
>
> You can find more interesting stuff at Ant's "mutant" proposal. There is
> an interesting "ClassIntrospector" class by Stefan Bodewig and Conor
> MacNeill, also in Ant's CVS repository at:
> /proposal/mutant/src/main/org/apache/ant/core/execution
>
> To avoid collision between mapped methods and the Component own methods,
> I just added a very simple interface:
>
> public interface AutoConfigurable
> {
> public Object getAutoConfigBean();
> }
>
> which redirects "introspected configuration" to another (possibly inner)
> object.
>
> So, the basic algorithm of the "introspected configuration" that the
> Configurator performs goes along these lines (simplified):
>
> public void configure( Object i_target, Configuration i_configuration )
> throws ConfigurationException
> {
> if ( i_target instanceof Configurable )
> ((Configurable)i_target).configure(i_configuration);
> else
> {
> boolean isAutoCfg = (i_target instanceof AutoConfigurable);
>
> Object autoCfgTarget;
>
> if (isAutoCfg)
> autoCfgTarget =
> ((AutoConfigurable)i_target).autoConfigBean();
> else
> autoCfgTarget = i_target;
>
> // The introspected Ant-like bit:
> autoConfigure(autoCfgTarget, i_configuration);
> }
> }
I like the concept of "direct" or "inverted" configuration. Direct when
you get the data and configure yourself (as Avalon does today),
"inverted" is when somebody places the right stuff in the right position
(javabeans is just a very simple model that implements this).
As much as I think that javabeans are a very simple form of "inverted
configuration", I totally agree with you that there are more general
paradigm that could be explored in this direction.
> As in Ant, the introspected bean should provide methods to create beans that
> handle the creation of sub elements and these beans are configured as above,
> i.e.: trough Configurable or "introspected configuration".
>
> Example: when the Configuration element being processed by the Configurator
> for the current object has a sub element named "blacksheep"...
>
> <current name="xpto" ...>
> <blacksheep name="xyz" ...>
> ...
> </blacksheep>
> ....
> </current>
>
> ...and the current object has a createBlacksheep() method with no arguments
> and returning an Object, this method will be invoked to obtain the child
> object that will be configured with the "blacksheep" sub element. This will
> be achieved just by calling the Configurator.configure() method described
> above, as in:
> configure(childObject, subElement);
> where:
> - "childObject" the object returned by createBlacksheep();
> - "subElement" is the <blacksheep> Configuration sub element.
> Notice that there can be other idioms to create a child element besides a
> createElementname().
Yes, the paradigm is general much more complex. Reminds me of XML data
binding (Castor and friends).
> The important thing is that it will be configured just
> as its parent, and the same for its possible children, and so on and so on
> in a recursive way. This includes having a child that implements
> Configurable and just gets configured the "old way" (as all components now
> are in Cocoon).
I love this flexibility! I really do.
> The method that creates the child bean and the bean itself decide the
> behavior of the child element addition.
Looks very brilliant.
> One of the bonus of using a Converter with this mechanism is that I do not
> have to care about calling ANY Congiguration methods, I just have to care
> about declaring fields of the right type (which includes File's and Date's
> and so on) and be careful to add a new conversion rule to the Converter
> when I add a new data type to my little universe.
Cool.
> I see no reason why the configuration has to be FLAT. Actually, I find
> it much easier to build deep configurations with this mechanism.
Understood and totally granted.
> The funny thing is that there is nothing complicated about this whole
> thing. It is just assembling simple components in a simple but powerful
> way.
>
> I am very interested in any feedback you might have to this stuff since I
> consider the configuration functionality as one of the core features of
> this framework.
Why don't you donate us your code? :) I love this approach (even if we
should probably talk about this over to Avalon-land)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
