cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [CRAZY IDEA] sitemaps in javascript
Date Mon, 30 Jan 2006 16:19:56 GMT
Bob Harner wrote:
> Hello everybody,
> One of my coworkers recently commented that Cocoon's sitemap files
> were really programs in the "xmap" language, rather than documents,
> and that as a language xmap is awkward and not very expressive.

That's right: sitemap is programming language specialized in building 
XML pipelines. As such, it has statements (all the <map:*>), variables 
(result of matchers and input modules) and control structures (actions, 
matchers and selectors).

> He suggested that the sitemaps should instead be written in a general
> purpose server-side interpreted language, maybe javascript.  I was
> horrified at the idea at first, but I've been thinking about it a
> little more and I think he just may be right.  Yes, I hear you all
> groaning :-)

Certainly not :-)

Read "Cocoon 3.0: the necessary mutation" [1]

> I have no standing in the Cocoon community and am just a lurker on
> this list, but this issue hits at the core of why I think Cocoon
> hasn't become more popular: there is too much to learn (and
> especially, too many languages). So I'm going to propose this
> unorthodox (crazy?) idea to the community and just let you smarter
> folks toss it around if you think it has any merit.

Interesting to see how quickly the "lurker" came to the same ideas as 
those that old-timers took years to have :-)

> First, I understand that sitemaps are intended to have relatively
> little functionality so that the the complex activity is forced into
> the components themselves.  But people inevitably find ways to make
> sitemaps complex anyway, with lots of deeply nested matches/selects
> and {../2} junk and "global" input module references and other nasty
> stuff.  This leads to very complex sitemap files that are hard to
> follow and very fragile.  Using a more complete functional or
> object-oriented language rather than a declarative language would help
> there.
> === A very simple example ===
> <map:match pattern="doclist/xdocs/**book.xml">
>     <map:generate src="xdocs/{1}book.xml"/>
>     <map:transform src="stylesheets/doclist.xsl">
>         <map:parameter name="uri" value="{1}"/>
>     </map:transform>
>     <map:serialize type="xml"/>
> </map:match>
> and the javascript equivalent:
> if (Request.uri.match (/doclist/xdocs/.*book.xml/')
> {
>     var bookpath = RegExp.$1;     // give what matched a name
>     document.generate.file ("xdocs/" + bookpath + "book.xml");
>     document.transform.xsl ("stylesheets/doclist.xsl", [uri, bookpath]);
>     document.serialize.xml();
> }
> This is just one way this could be done, of course.  Smarter people
> than me can probably think of even more elegant ways to express a
> pipeline.
> A few more points:
> * Most Java developers already know Javascript to some degree, so this
> would be one less language for a user & developer to learn.

Yep. And many of Cocoon users that don't know Java can write a bit of JS 
(see the success of flowscript).

> * Sitemap "resources" could be real javascript functions (or methods),
> with clear argument lists.


> * Eclipse has much better editor support for Javascript than xmap,
> with the several quality plugins available.

Yep. Especially with the amazing Interakt JSEclipse plugin [2]

> * Cocoon already uses server-side Javascript for scripting Java
> (cocoon flow using Rhino).
> Okay, you all think I'm crazy.  I can live with that.  But just give
> the idea a few minutes to sink in before dismissing it.

You're not crazy, but totally on track with some of the thoughts that 
have been lying around on this list recently! Thanks for this :-)



Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message