cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ivelin" <>
Subject Re: [RT] the quest for the perfect template language
Date Tue, 08 Apr 2003 02:35:23 GMT

XQuery might be one option that is endorsed by the W3C.
It uses non-xml syntax and is relatively intuitive to read.

I've played with it in the recent months and am starting to recognize its
There is one GPL implementation by Per Bothner:
I haven't found one under LGPL or ASL, but was informed that the Xalan team
is about to release an early version to the public. They actually had
something published in the CVS tree but was later pulled out.


----- Original Message -----
From: "Stefano Mazzocchi" <>
To: <>
Sent: Monday, April 07, 2003 8:48 AM
Subject: Re: [RT] the quest for the perfect template language

> on 4/6/03 4:17 AM Geoff Howard wrote:
> > OK, I'm regretting sending that message - the tone is wrong and
> > I missed the point.  Stefano was talking about a revolutionary
> > idea and I just said "hey, you're talking about a revolutionary
> > idea".  He was asking why people weren't jumping in on it and I
> > wanted to explain why I wasn't and I think air a below the surface
> > concern I had, which is just that reinventing the wheel is an
> > "anti-pattern" - but then again so is continuing to drive on a flat
> > tire.
> Well put.
> I'm getting more and more concerned about the maintanance costs of
> transformation-based templating compared to generation-based templating.
> And I'm expressing my concerns.
> I also stated that XSLT seems to be pretty close to providing a solution
> for a generation-based template system that is efficient and easy to
> write, but its syntax will very likely be to hard to use for the people
> that will have to write the templates.
> *thus*, I thought about creating a non-xml syntax that can be one-2-one
> converted to XSLT.
> I don't give a damn if I'm the only one who wants to do this. If I think
> I need it, I'm going to do it anyway, even if I'm alone (but it seems
> I'm not the only one who shares concerns about the XML xslt syntax)
> Should I remember you that I was one of the first that wanted to use
> XSLT for server side while almost everybody else at that time told me I
> was nuts?
> I rethink my strategies *exactly* when they become mainstream and I keep
> a very open minded view about things.
> I try to teach everybody I work with to do the same, but it's a very
> hard job. One must have a pretty solid self-confidence to be able to
> question his/her foundations continously.
> I have learned the very hard way, in my life, not to take for granted
> that everybody is able to do it.
> But then again, no need to apologize, since I'm not offended anymore by
> these things :-)
> > I'm not bothered much by the xml syntax and I still think some of the
> > points from my last message apply but I definitely resonate with the
> > other core problems.
> RT are just that: random thoughts.
> If they grow into more solid things, great, if not, well, darwin teaches
> that most mutations are harmful to a genetic strain. but this never
> stopped evolution to do its job rather magnificently.
> > How many of these problems would be solved by some combination of:
> > - Preprocessing xml to provide a structure more conducive to the
> > type of rule based processing that xslt excels at (like providing
> > count and position information).  I wriggled my way out of several
> > tricky xsl programming issues by simply providing more information
> > coming out of the generator.
> Definately true. Look at my Paginator in the scratchpad. It does full
> pagination and has a flexible 'pagesheet' that you can apply to
> different streams. It could have been done with a stylesheet, but they
> tended to become much harder to maintain than java code.
> > - Creating a flexible, reusable library of xsl template rules to
> > perform the most common but non-trivial tasks.  Along these lines,
> > I have been needing a good crossbrowser dhtml menu implemented with
> > xslt and have found nothing, though there are many javascript-only
> > solutions.  I'd much rather have the heavy lifting of creating the
> > menu structure performed (and cached) serverside but it's just so
> > easy to plug in the javascript only version.
> Imported XSLT become obscure black boxes and you end up rewriting them
> yourself most of the time.
> I have a tendency to think that XSLT is just like perl: write it for
> your simple little needs and prepare to throw it away.
> If you can do that, it shines. It's beautiful and very elegant.
> But if you plan to reuse it, well, don't! simply use a different
> language :-)
> But this has probably something to do with my mindset, so if you
> disagree, I really don't care, as long as I have the freedom to do what
> I need, I'm happy.
> I'm not the type of guy that will impose *my* way of reasoning on you
> simply because I think it's the best I could find.
> I will just talk about it and give you the freedom to use experience it
> yourself, then I'll let you decide. And respect you along with your
> differences.
> Too bad this kind of attitude seems to be getting more and more rare
> nowadays.
> --
> Stefano.

View raw message