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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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:[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]
