You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/07/27 23:34:39 UTC
[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/
Re: [RT] A Groovy Kind of Sitemap
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 28/lug/04, alle 12:59, Vilya Harvey ha scritto:
> Ugo Cei wrote:
>> Il giorno 28/lug/04, alle 09:56, Vilya Harvey ha scritto:
>>> Interesting idea. Just out of curiosity, why Groovy and not
>>> JavaScript?
>> I wrote it in my RT, because it's trendy ;-)
>
> Fair enough. :-) Do you intend to use Groovy in other places
> throughout Butterfly, or just for the sitemap? It would be nice to be
> able to use it for flow control, form validators/event handlers, etc.
Flowscript is what comes to mind at first. I think we have already
(thanks to Antonio) most of what is needed, except continuations. But
as far as the sitemap is concerned, I'm not that fond of Groovy to
really push it as *the* alternative to XML. It's just something that is
available now to experiment new ideas without having to do a BDUF(1) or
write a lot of code. Don't get so focused on the pros and cons of
Groovy that you fail to see the forest instead of the trees ;-).
Ugo
1: Big Design Up-Front
--
Ugo Cei - http://beblogging.com/
Re: [RT] A Groovy Kind of Sitemap
Posted by Antonio Gallardo <ag...@agssa.net>.
Vilya Harvey dijo:
> Ugo Cei wrote:
>> Il giorno 28/lug/04, alle 09:56, Vilya Harvey ha scritto:
>>
>>> Interesting idea. Just out of curiosity, why Groovy and not JavaScript?
>>
>>
>> I wrote it in my RT, because it's trendy ;-)
>
> Fair enough. :-) Do you intend to use Groovy in other places throughout
> Butterfly, or just for the sitemap? It would be nice to be able to use it
> for flow control, form validators/event handlers, etc.
I proposed that a cople of weeks ago. I think it is a good idea:
repleacement of JS with Groovy.
The advantage of Groovy over JS is that it integrates better with java
than other script languages. In the JS case we have some problems while
translating some object values and there are some hacks to call java
classes inside JS. In the Groovy case it is more natural, because it was
one of the targets since the beginning. This is why Grovvy is better than
JS.
Best Regards,
Antonio Gallardo
Re: [RT] A Groovy Kind of Sitemap
Posted by Vilya Harvey <vi...@lineone.net>.
Ugo Cei wrote:
> Il giorno 28/lug/04, alle 09:56, Vilya Harvey ha scritto:
>
>> Interesting idea. Just out of curiosity, why Groovy and not JavaScript?
>
>
> I wrote it in my RT, because it's trendy ;-)
Fair enough. :-) Do you intend to use Groovy in other places throughout
Butterfly, or just for the sitemap? It would be nice to be able to use it
for flow control, form validators/event handlers, etc.
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
Re: [RT] A Groovy Kind of Sitemap
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 28/lug/04, alle 09:56, Vilya Harvey ha scritto:
> Interesting idea. Just out of curiosity, why Groovy and not JavaScript?
I wrote it in my RT, because it's trendy ;-)
--
Ugo Cei - http://beblogging.com/
Re: [RT] A Groovy Kind of Sitemap
Posted by Vilya Harvey <vi...@lineone.net>.
Interesting idea. Just out of curiosity, why Groovy and not JavaScript?
Vil.
--
__
o| _. / \|o._ _ _ ._ _ ._ _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
/ \__
http://website.lineone.net/~vilya
Re: [RT] A Groovy Kind of Sitemap
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ugo Cei wrote:
> Il giorno 30/lug/04, alle 00:24, Sylvain Wallez ha scritto:
>
>> 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.
...
One thing I *hate* about flowscript is that it's in a different file
from the sitemap. Kinda like writing a java class with methods in one
file and fields in another.
Having both in the same file, even if with a different language but
still with a readable format (like python), would be really cool.
cocoon<<<
version = 2
sitemap--->
mypipeline
if (request.match(".*\.html")) then
generate("input.xml")
transform("xslt", "stylesheet1.xsl")
transform("xslt", "stylesheet2.xsl")
serialize("xml")
<---
javascript--->
void myfunction(continuation,javascript){
blah...blah...
(can call "mypipeline" pipeline from here)
(can call "mypipeline2" pipeline from here)
}
<---
sitemap--->
mypipeline2
if (request.match(".*\.html")) then
generate("input.xml")
transform("xslt", "stylesheet1.xsl")
transform("xslt", "stylesheet2.xsl")
serialize("xml")
<---
jtyhon--->
myfunction(continuation)
blah...blah...
(can call "mypipeline" pipeline from here)
(can call "mypipeline2" pipeline from here)
<---
>>>
> So I needed something that could enable me to reach very
> rapidly the target of having an actual program that would be able to
> take an HTTP request, feed it to a sitemap that is (semantically if not
> syntactically) equivalent to a subset of the Cocoon sitemap and send out
> an appropriate response.
One attempt is the CocoonBean, that has tried to do this by wrapping
instead of redoing. Same problem, different implementation. Personally i
think that it's wierd to have a bean wrap a component wrap some classes,
although necessary not to redo things (like you are doing :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] A Groovy Kind of Sitemap
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 30/lug/04, alle 00:24, Sylvain Wallez ha scritto:
> 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.
I'm not taking this badly at all, Sylvain :-) I am perfectly aware of
the risks involved in such an attempt. Indeed I wrote (and you
quoted): "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)".
One of the reasons I came up with this "design" is that I'm trying to
adopt a "tracer bullet" type of approach (if you haven't read Hunt and
Thomas' "The Pragmatic Programmer" I suggest that you grab a copy and
read it, it's highly recommended, or else you can find a description
here [1]). So I needed something that could enable me to reach very
rapidly the target of having an actual program that would be able to
take an HTTP request, feed it to a sitemap that is (semantically if not
syntactically) equivalent to a subset of the Cocoon sitemap and send
out an appropriate response.
I'm cutting short on this since I'm writing from the hall of my hotel
(thanks to WiFi) and I should actually be already at my customers', but
I think I got great feedback from you and from all the other people who
participated in this thread. Starting tomorrow, I'll be on vacation for
one week, but fully connected, so I hope to find the time and the
clarity of mind to come up with something less dumb and simpleminded.
Stay tuned!
Ugo
[1] http://www.artima.com/intv/tracer.html
--
Ugo Cei - http://beblogging.com/
Re: [RT] A Groovy Kind of Sitemap
Posted by Sylvain Wallez <sy...@apache.org>.
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
done.
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
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] A Groovy Kind of Sitemap
Posted by Tony Collen <co...@umn.edu>.
Torsten Curdt wrote:
>> Sinful as it might sound, I had been thinking about a non-XML syntax
>> for the sitemap for a long time ;-)
>
>
> Well, I have to admit I came across this
> thought too lately.
>
> Pipelines quite often felt like functions
> to me. The virtual components thread always
> remembered me on a call hierarchy.
>
> Lately I've been using antlr to create
> a lexer/parser and I was even wondering
> if the in memory tree representation of
> the sitemap is maybe nothing more than
> an abstract syntax tree.
This is another thing I was talking with Ugo about, in fact, I brought
it up because something like a lexer/parser combo on a basic sitemap
grammar would be the "simplest" way to do it, IMO.
Which raises the question: What happens if we can do continuations
directly inside the pipeline?
Tony
Re: [RT] A Groovy Kind of Sitemap
Posted by Torsten Curdt <tc...@vafer.org>.
> Sinful as it might sound, I had been thinking about a non-XML syntax for
> the sitemap for a long time ;-)
Well, I have to admit I came across this
thought too lately.
Pipelines quite often felt like functions
to me. The virtual components thread always
remembered me on a call hierarchy.
Lately I've been using antlr to create
a lexer/parser and I was even wondering
if the in memory tree representation of
the sitemap is maybe nothing more than
an abstract syntax tree.
I guess it would help to make the
sitemap a little less verbose.
I guess I like the idea...
cheers
--
Torsten
Re: [RT] A Groovy Kind of Sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
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]
--
Stefano.
Re: [RT] A Groovy Kind of Sitemap
Posted by Brian McCallister <mc...@forthillcompany.com>.
I love it!
-Brian
On Jul 27, 2004, at 5:34 PM, Ugo Cei wrote:
> if (match ".*\.html") {
> generate "input.xml"
> transform "xslt", "stylesheet1.xsl"
> transform "xslt", "stylesheet2.xsl"
> serialize "xml"
> }
Re: [RT] A Groovy Kind of Sitemap
Posted by Reinhard Poetz <re...@apache.org>.
Ugo Cei wrote:
> Il giorno 28/lug/04, alle 20:01, Stefano Mazzocchi ha scritto:
>
>> Subclipse runs just fine on eclipse for osx.
>
>
> Last time I tried it crashed Eclipse without mercy. But I remember
> seeing a blog post somewhere detailing how to properly configure it
> with security and all the rest. In case I don't succeed I will bug you
> :-)
>
> BTW, is HTTPS required for write access to the repo?
>
>>> Anyway, in order to at least do a quick checkin from the command
>>> line, how is our SVN repo structured and what would be the URL where
>>> to put this stuff?
>>
>>
>> see, that's the beauty of SVN: nobody cares, since we can move it
>> whereever we want later on ;-)
>
>
> OK, I'll explore what we have and make up my mind later.
>
> Ugo
>
See http://wiki.apache.org/cocoon/SubversionMigration - I try to keep
the Subclipse section up2date.
--
Reinhard
Re: [RT] A Groovy Kind of Sitemap
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 28/lug/04, alle 20:01, Stefano Mazzocchi ha scritto:
> Subclipse runs just fine on eclipse for osx.
Last time I tried it crashed Eclipse without mercy. But I remember
seeing a blog post somewhere detailing how to properly configure it
with security and all the rest. In case I don't succeed I will bug you
:-)
BTW, is HTTPS required for write access to the repo?
>> Anyway, in order to at least do a quick checkin from the command
>> line, how is our SVN repo structured and what would be the URL where
>> to put this stuff?
>
> see, that's the beauty of SVN: nobody cares, since we can move it
> whereever we want later on ;-)
OK, I'll explore what we have and make up my mind later.
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] A Groovy Kind of Sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 28/lug/04, alle 00:45, Stefano Mazzocchi ha scritto:
>
>> Ugo Cei wrote:
>>
>>> (you can find it in Butterfly's CVS)
>>
>>
>> the SVN repository has been setup. It would be nice to have that
>> development over on SVN since we could see what's going on ;-)
>
>
> I just finished reading the Subversion book, but have still to try it on
> my Powerbook. It would be great to have Subclipse running on OSX, since
> I'll cry if I have to give up the ease of use given by Eclipse's CVS
> integration.
Subclipse runs just fine on eclipse for osx.
> Anyway, in order to at least do a quick checkin from the command line,
> how is our SVN repo structured and what would be the URL where to put
> this stuff?
see, that's the beauty of SVN: nobody cares, since we can move it
whereever we want later on ;-)
--
Stefano.
Re: [RT] A Groovy Kind of Sitemap
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 28/lug/04, alle 00:45, Stefano Mazzocchi ha scritto:
> Ugo Cei wrote:
>
>> (you can find it in Butterfly's CVS)
>
> the SVN repository has been setup. It would be nice to have that
> development over on SVN since we could see what's going on ;-)
I just finished reading the Subversion book, but have still to try it
on my Powerbook. It would be great to have Subclipse running on OSX,
since I'll cry if I have to give up the ease of use given by Eclipse's
CVS integration.
Anyway, in order to at least do a quick checkin from the command line,
how is our SVN repo structured and what would be the URL where to put
this stuff?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] A Groovy Kind of Sitemap
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> Ugo Cei wrote:
>
>> (you can find it in Butterfly's CVS)
>
>
> the SVN repository has been setup. It would be nice to have that
> development over on SVN since we could see what's going on ;-)
>
What is the repository address? Noone updated the docs yet.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] A Groovy Kind of Sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> (you can find it in Butterfly's CVS)
the SVN repository has been setup. It would be nice to have that
development over on SVN since we could see what's going on ;-)
--
Stefano.