Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of bobharner@gmail.com designates
 66.249.82.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=FXVQ652+SR6KiVF5AtDDm36FcUjP6O4q/tBgEq+IwrL2kNDusiq23fwXL1rp/+sPCn9IbWdkCuSCe26tddxzhAvfThiAPu/61N7CN1F1BFKGV+TyhPY+J/xxE3fc4snyr5FPiA4SM2T+jbMUcHuLWTqvRu128YjKh6zrE74m6Vo=
Message-ID: <a81bf3880601300804v5f3c4e00q131fc458ba16824c@mail.gmail.com>
Date: Mon, 30 Jan 2006 11:04:22 -0500
From: Bob Harner <bobharner@gmail.com>
To: dev@cocoon.apache.org
Subject: [CRAZY IDEA] sitemaps in javascript
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.  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 :-)

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.

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.

=3D=3D=3D A very simple example =3D=3D=3D

<map:match pattern=3D"doclist/xdocs/**book.xml">
    <map:generate src=3D"xdocs/{1}book.xml"/>
    <map:transform src=3D"stylesheets/doclist.xsl">
        <map:parameter name=3D"uri" value=3D"{1}"/>
    </map:transform>
    <map:serialize type=3D"xml"/>
</map:match>

and the javascript equivalent:

if (Request.uri.match (/doclist/xdocs/.*book.xml/')
{
    var bookpath =3D 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.

* 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.

* 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.