cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: Interpreted sitemap
Date Thu, 08 Nov 2001 19:40:41 GMT
On Thu, 08 Nov 2001 16:21:23 +0100, Sylvain Wallez <sylvain.wallez@anyware-tech.com>
wrote:

> Ovidiu Predescu a écrit :
> > 
> > On Wed, 07 Nov 2001 10:21:59 +0100, Sylvain Wallez <sylvain.wallez@anyware-tech.com>
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 <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)

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


Mime
View raw message