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 ? Right, but if you do this way the contract between the components of the pipeline is still a ContentHandler. What I was thinking is to have the ability to create pipelines whose components use a different contract that of a ContentHandler. For pipelines that do processing on objects that contain among other things XML docs, this makes sense. > > > 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. OK, I'll take a look at your code today to see your idea. > > > > Could you describe a bit your approach? > > > > > > Well, I wanted the structure of this to be stabilized, at least from my > > > point of view, before committing it into CVS. This should be in a few > > > days, or the beginning of next week. If you can't wait, I can open a > > > scratchpad area and put it in, but with no warranty of what comes in ;) > > > > Yes, I would definitely be interested in taking a look at it. It > > doesn't need to compile necessarily either ;-) So if you can put it in > > a scratch-pad area that would be great! > > Ok, I've put it in $cocoon/scratchpad. It compiles, but is largely > incomplete and "subject to change without notice" (TM) : I'm not fully > satisfied by the CM stuff I've written. This is great, thank you! > Comments welcome :) I'll give you more feedback once I look on the code. Thanks, Ovidiu -- 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) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
