cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corin Moss" <Corin.M...@tvnz.co.nz>
Subject RE: [RT] A Groovy Kind of Sitemap
Date Tue, 27 Jul 2004 22:02:46 GMT

Hi,

Speaking from the perspective of a Cocoon user with a probably larger
than normal install base, I'd be _very_ scared about upgrading to a new
version of Cocoon if my old sitemaps don't work.  I realise that the
work you're doing is research focused, but I still think a bit of
pragmatism is in order.  IMHO the new version of Cocoon should at the
very least allow me to use my existing sitemaps as is.  I guess if you'd
really like a Groovy based sitemap declaration, then existing XML
sitemaps could be pre-parsed into Groovy?

Also - why would you like to get away from XML based sitemap
declarations?  We've found them to be very powerful, and the fact that
they're XML based certainly lessens the learning curve for new
developers :)

Anyway - just my initial questions - I'm watching with a lot of interest
the work you're doing here.

Regards,

Corin
-----Original Message-----
From: Ugo Cei [mailto:ugo@apache.org]
Sent: Wednesday, 28 July 2004 9:35 a.m.
To: Cocoon-Dev
Subject: [RT] A Groovy Kind of Sitemap


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.

	WDYT?

		Ugo

--
Ugo Cei - http://beblogging.com/

================================================================
CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

================================================================
For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz
================================================================

Mime
View raw message