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 Sat, 10 Nov 2001 06:13:04 GMT
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 <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 ?

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 <ovidiu@cup.hp.com>
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message