cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Interpreted sitemap
Date Fri, 16 Nov 2001 12:33:59 GMT
Hi Ovidiu,

> If this is right, what is the advantage over the current model used by
> Ant?

Actually, the point I was making was on the advantages over the current
model used by _Avalon_ and Cocoon, after Stefano remarks.

Notice also that I do not exactly follow Ant rules. It is "Ant-like" but
it is not the same thing.

Comparing with Ant:
  - Full control of configuration processing for Components that implement
    the Configurable interface, which also means Avalon compatibility;
  - Avoiding collision between the methods and properties meant to be used
    by the introspected configuration and the "working" methods of the
    component by giving another (inner?) bean as target for this
    introspected configuration (trough the AutoConfigurable interface).
    In Ant one has to be very careful on naming all the "working" methods
    of a component in order to avoid that they get "configured" by
    accident;
  - _Optional_ further simplification of the above configuration beans by
    using public field introspection instead of the usual bean stuff;
  - Much more flexible/configurable type conversion (parsing) rules;
  - BETTER than that, you just have to change the implementation of that
    Configurator object to change your configuration strategy to suite
    new needs.

I must repeat that a lot of this was inspired by Peter Donald's proposal.
Not that many new ideas.

I only ended up with a brand new implementation because, considering
other stuff I already had, it was the shortest path to the extra
flexibility and performance I wanted.


My experience is that it really makes it much easier to make components
configurable. And the configuration does NOT have to be flat at all.


Again, I am very interested on any feedback on these ideas.


Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de



> -----Original Message-----
> From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com]On Behalf
> Of Ovidiu Predescu
> Sent: Thursday, November 15, 2001 6:16 PM
> To: Paulo Gaspar
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: Interpreted sitemap
>
>
> Hi Paulo,
>
> Your framework sounds interesting.
>
> If I understand your framework correctly, the introspected beans have
> to follow the same API as that required today by Ant. The difference
> however lies in the implementation, as your framework uses Avalon to
> parse the XML config file. Avalon will create a tree of Configuration
> objects, which are then traversed by your framework to setup the
> beans.
>
> If this is right, what is the advantage over the current model used by
> Ant?
>
> Thanks,
> --
> Ovidiu Predescu <ovidiu@cup.hp.com>
> http://orion.rgv.hp.com/ (inside HP's firewall only)
> http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs,
> other stuff)
>
>
> On Tue, 13 Nov 2001 20:52:29 +0100, "Paulo Gaspar"
> <paulo.gaspar@krankikom.de> 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.
> >
> > 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:stefano@apache.org]
> > > Sent: Monday, November 12, 2001 4:35 PM
> > > To: cocoon-dev@xml.apache.org
> > > 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.
> > > <stefano@apache.org>                             Friedrich Nietzsche
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message