cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject [RT] A Groovy Kind of Sitemap
Date Tue, 27 Jul 2004 21:34:39 GMT
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.



Ugo Cei -
View raw message