cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Wed, 24 Oct 2001 20:03:26 GMT
On Fri, 5 Oct 2001, Sylvain Wallez wrote:

> Peter Royal a écrit :
> >
> > At 12:31 PM 10/5/2001 +0200, you wrote:
> > >Here I have the feeling we are doing the same mistake over again: the
> > >sitemap was compiled when no hotspot tecnique was present and we had to
> > >avoid excessive use of esternal recurrent logic when we could "unroll"
> > >the tree traversal and let java execute it directly by transforming it
> > >in code.
> >
> > I think the sitemap is really metadata that configures the cocoon engine.
> > So in that respect are we mixing concerns by converting metadata into
> > program code?
> >
> > I took your previous words about the removal of hotspots and applied those
> > to our XSP pages in house. Before I was recreating the same java code
> > repeatedly. As an answer to the hotspot issue, I moved the code into a
> > separate class file with static methods, just like many of the internal
> > logicsheets.
> >
> > I mention this because maybe we could apply some of the same techniques to
> > the sitemap? Rather than generating a bunch of different methods, etc,
> > could we not just compile the sitemap to a bunch of static variables
> > (metadata) with method calls to do the actual work? Thus gaining some of
> > the benefits of hotspotting? That might provide a migration plan towards a
> > more radical design. It might also be
> >
> > As more and more people come on board using version 2, we need to protect
> > the investment people are making in the current sitemap model. At least
> > from the standpoint of providing a seamless transition to what is next, in
> > both functionality and brain power required to understand.
> The transition is assured by using the same syntax, and I'm not sure it
> would have to be changed with an interpreted engine. The only
> compatibility break would be for CodeFactory selectors and matchers :
> those ones would have to be rewritten as regular components. So I think
> an interpreted sitemap engine could integrate smoothly in the current
> architecture.

I'm not so enthusiastic about rewriting the sitemap engine from
compiled to interpreted. Rather a new approach for the hole
URIspace-/Flow-/resource-definition should be taken (as Berin proposed).

> The problem is different for XSP : the language contains primitives such
> as <xsp:page language="xxx">, <xsp:logic>, <xsp:expr>, etc, which are
> inherently related to the notion of programming language. I use the same
> approach as yours for logicsheets (static methods), which along with
> XSP-code size reduction, eases debugging a lot !
> There has been recently some long threads about alternatives to XSP,
> mostly based on introspection transformers (see also x:forge at
> Those may be easier to use than XSP (I wish java
> had a #LINE directive like good old C compilers to set line numbers in
> the generated class files !), but could hardly be as fast because of the
> use of introspection.

Yes, even for XSP I think new approaches will be better than rewrites.
You know, code-to-java production was very popular those days but as
with Cocoon 1.x vs. Cocoon 2.x (or better DOM vs. SAX) practice let you
learn new lessons.


> > I have been enjoying the recent RT threads though. I do appreciate that
> > such discussions take place out in the openness of the dev list. Of course
> > that is what makes open source software so great :)
> Same here, even if time available for OSS isn't as big as I would like
> it to be :(
> Sylvain
> > keep hacking.
> > -pete
> >
> > --
> > peter royal ->
> > managing partners, inc. ->
> >

To unsubscribe, e-mail:
For additional commands, email:

View raw message