Hi Sylvain, I finally had time to look at the new implementation of the sitemap code. It's looking good!
On Thu, 08 Nov 2001 16:21:23 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > Ovidiu Predescu a écrit : > > > > On Wed, 07 Nov 2001 10:21:59 +0100, Sylvain Wallez ><[EMAIL PROTECTED]> wrote: > > > > > > One of the my requirements for this re-implementation is to allow > > > > things other than SAX events to flow on the pipeline. I'm specifically > > > > thinking of Java objects that could represent the incoming HTTP > > > > request as an object, for unorthodox types of processing. Of course > > > > the interfaces of the components in the pipeline have to be compatible > > > > for such an approach to work. > > > > > > Could you explain in more detail these unorthodox types ? Can't this be > > > solved by a custom Environment implementation and/or a Generator ? > > > > I don't think it can, but maybe you can prove me wrong. > > > > What I need is the ability to have a custom generator that reads the > > input HTTP request, and constructs a Java object out of it. > > > > An example is when the SOAP message is actually SOAP with > > attachments. In that case I'd like to pass on the pipeline a JAXM > > SOAPMessage object, together with the output SOAPMessage object. The > > transformers will operate on incoming message and construct the > > outgoing message, as the processing flows through the pipeline. The > > trick is I still want to make use of the great XML processing > > capabilities of Cocoon, and don't want to reinvent a new framework for > > this. > > What about storing the object in the objectModel or in a Request > attribute ? This makes it available to every element of the processing > chain. Or did I miss something ? Nevermind, I think what I want to do can be implemented by passing the needed objects in the Environment as you suggested earlier, or even in the object model. > > > > My thoughts were to take the Ant XML->Java conversion engine, extend > > > > it to use the SAX2 API, and create Avalon components that represent > > > > the pipeline. The Ant engine is indeed a very simple, yet powerful and > > > > extensible way to create a hierarchy of Java objects from an XML > > > > document. > > > > > > Didn't know about this Java/XML stuff in Ant. I will look at it. > > > > It's a very simple way to hook up Java objects. Essentially each XML > > element is represented by a Java class. For each child element of this > > element you need to implement an add<ChildElementName>(<ClassName>) > > method. For each attribute understood by your element, you need to > > implement a set<AttributeName>(<type>) method. Now you do have some > > constructs by which you can add to an element _any_ element you like, > > which is very useful when you want your element to support arbitrary > > elements. > > > > The Ant engine starts reading the XML file and during the SAX parsing > > it creates the necessary objects and hooks them up as needed. After > > the whole Java tree gets constructed this way, it will invoke the > > execute() method on the topmost object. This triggers the execution of > > the build. > > I've looked at it : it's nice, but doesn't exactly correspond to what I > need. > > Firstly, the new TreeProcessor reads sitemap.xmap in a > so-easy-to-process Avalon configuration, while Ant is entirely > SAX-based. However, it would be good to have a Configuration2JavaBean or > something like that. Have to think about it. > > Secondly, and more important : the tree of processing objects isn't > built directly from the XML tree. The sitemap file is used to build a > tree of NodeBuilder objects, that in turn create the actual > ProcessingNodes that will process the environment. This allows the > builders to choose between different implementations of ProcessingNode > depending on the environment : use of threadsafe or single-threaded > components, disctinction between PreparedMatcher and Matcher, etc. This > is key for maximum speed at process time. I believe there is a fundamental difference between the way Avalon and Ant process an XML configuration file. 1) Avalon reads the whole XML file and creates a hierarchy of Configuration objects. You then obtain the top level Configuration object and start constructing your data structure from this data. In a sense the Configuration data structure is very similar with a DOM tree. The Ant SAX-based engine eliminates the need to create such an intermediary data structure. Instead the Ant engine creates the data structure as it processes the SAX events. The result of the parsing is exactly the data structure you need. 2) With the Avalon model, the code for constructing the final data structure is spread along the classes that represent the data structure. Each class has to define how to map from a Configuration object into its own representation, and has to deal with loading and instantiation of the classes corresponding to their subelements. With Ant, this whole logic is hidden inside the SAX based engine. The only thing the class should be concerned with is implementing the right set<Attribute> and/or add<Element> methods, depending on the attributes or elements they support. 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. Obviously you can achieve exactly the same results with either model. What matters is the design of the final data structure. This is what will be used at execution time, not the intermediary data structures created when reading the config file or the sitemap. Other than the way the config file/sitemap are read the final runtime data structure looks very nice. Even though its incomplete I can see where you're headed. So far I like the approach, so keep up the good work! I'm sure we'll have a very nice and fast sitemap implementation pretty soon. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.nsr.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) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
