> 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.
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.
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.
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);
}
}
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(). 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).
The method that creates the child bean and the bean itself decide the
behavior of the child element addition.
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.
I see no reason why the configuration has to be FLAT. Actually, I find
it much easier to build deep configurations with this mechanism.
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.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 12, 2001 4:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Interpreted sitemap
>
>
> Ovidiu Predescu wrote:
>
> > The two models are more like a "pull" model in the Avalon case, as
> > opposed to a "push" model in the Ant case.
> >
> > Personally I prefer the push model (the Ant way), as it's much easier
> > to write and maintain over a longer period of time. The code that
> > deals with the loading and instantiation of the right classes is
> > centralized, thus you have to write it once and for all only in the
> > engine.
>
> 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.
>
> --
> 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]
