cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Thu, 29 Jul 2004 22:24:29 GMT
Ugo Cei wrote:

> Dear Cocooners,
> while working on Butterfly, I started looking at the TreeProcessor and 
> I was astonished at the number of classes I have to port, if I want to 
> reimplement it:
> o.a.c.components.treeprocessor: 26 classes
> o.a.c.components.treeprocessor.sitemap: 44 classes
> o.a.c.components.treeprocessor.variables: 4 classes
> Total: 74 classes.
> Some of these classes have a rather complex inheritance hierarchy. 
> Just to pick one at random: PreparableMatchNode inherits (directly and 
> indirectly) from 6 classes and 10 interfaces!
> Now this is a lot of code. Kudos to Sylvain for coming up with it and 
> I'm sure the design is the best possible, given the constraints.

Mmmh... Thanks, but I easily admit that the TreeProcessor is 
over-designed, and I simplified it a bit recently. But a lot more can be 

This has to be put back in perspective with where Cocoon was at that 
time (in late 2001): there were lots of talks at that time about 
flowmaps, i.e. another way to write pipelines in a flow-oriented way. 
Therefore, I architected the TreeProcessor as an evaluation tree that 
provided some abstractions meant to ease the implementation of alternate 
*map languages.

A goal was also to achieve maximum performance, and therefore to 
strongly separate build-time classes (can be slow) from runtime classes 
(must be fast). Hence the separation between ProcessingNode and 
ProcessingNodeBuilder which doubles the number of classes. That goal was 
achieved, as the new interpreted engine was even a bit faster than the 
previous compiled one.

> But since, in doing Butterfly, I determined that we should not be too 
> constrained by backward compatibility, I started thinking about a 
> possible alternative, which should be, first of all, much simpler.
> One thing that we would probably like to do without is the 
> pointy-brackets kind of sitemap syntax. We could define a friendlier 
> syntax of our own devising or we could reuse something. Since I'm a 
> lazy butt and I like to reuse others' code whenever possible, I 
> decided to reuse an existing grammar and parser. And I wanted it to be 
> an executable grammar, that is a scripting language, since I wanted to 
> avoid writing the code to execute a data structure. Last, I wanted to 
> use something trendy ;-) so I came up with "A Groovy Kind of Sitemap" 
> (sorry, Phil):
>         if (match ".*\.html") {
>             generate "input.xml"
>             transform "xslt", "stylesheet1.xsl"
>             transform "xslt", "stylesheet2.xsl"
>             serialize "xml"
>         }

At first, it looks clean and simple. How would it look like with 
component parameters?

But thinking further, this turns the sitemap in a full-blown programming 
language (see the "if" you've written?). Where's SoC then? It took us 
months with flowscript to allow removing procedural-like code with 
actions from the sitemaps, and I have high fears that a Groovy sitemap 
(or any other scripting language) will lead to a big mixing of 
everything, far worse than actions.

I don't really understand the current trend against pointy-brackets. Is 
it that people come to hate what they used to love so much? One of the 
goals in the design of XML was to provide a syntax that would be both 
easily human-readable and easliy machine-processable. IMO, the goal was 
well achieved, otherwise we would not see XML everywhere today.

Human-readable also includes learning. With XML, you just have to 
concentrate on the semantics of the elements and attributes, and not on 
the syntactic details (braces, semi-colons, commas, etc). This is also 
an important point in making a tool or technology acceptable by people: 
there are so many XML dialects around that learning a new one is not 
considered a problem (although the sitemap brings much more than just a 
dialect). Using a different programming language however, is much more 
difficult and will often hit the "management wall", that won't accept a 
babelization of languages used on a project. I know this by experience 
with the JS used in flowscript.

And machine-processable not only means parsers, but also tools and IDEs. 
Building an auto-completion engine for a completely new syntax is way 
more difficult than feeding an XML editor with a schema. There are also 
more and more editors like Eclipse's plugin.xml editor (e.g. EasyStruts 
or Spindle), which can simply be described by mapping form fields to 
XPath expressions (could it be that I have something like this for the 
sitemap on my Mac? ;-)

> I have to admit I'm ashamed at how bad and simpleminded the 
> implementation of this is (you can find it in Butterfly's CVS). And 
> propbably using a full-fledged scripting language isn't such a good 
> idea (I already see people putting database access code in the 
> sitemap), but it took no more than two hours to implement (one and 
> half spent trying to make sense of Groovy's scattered docs), so it's 
> definitely simple.
> Implementation details aside, I think this is something that we can 
> experiment with. I propose to adopt a pragmatic approach: do not try 
> to design the best possible sitemap syntax, but instead use what is 
> readily available (Groovy) and try to push it to the limits. If it 
> breaks before it's actually useful, we'll think of something else.

Well, IMO, try something else now before the sitemap concept gets killed 
by changing it into a pipeline-building extension of a scripting language.

Don't take all this badly Ugo: I see much more dangers in turning the 
sitemap into a scripting language than the advantages brought by saving 
a few keystokes or the ease of implementation. But I'm all for a 
simplified implementation of the current syntax. Something that once 
came to my mind as a possible way to implement the sitemap engine (and 
also JXTG) is Jelly, provided by the same James Strachan that made 
Groovy after he came to dislike pointy brackets.

Sylvain (trying to follow RTs while on vacation)

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message