cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Tue, 27 Jul 2004 22:04:22 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. 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"
>         }
> 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.

Sinful as it might sound, I had been thinking about a non-XML syntax for 
the sitemap for a long time ;-)

Now, if you want to have me completely happy, add the abilityt to run 
java as it was a scripting language (no need for recompilation and 
start/stop the container)

[chris already wrote the code for that, it's just a matter of 
integrating it inside the core]


View raw message