Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41F00D7B.6030605@nada.kth.se>
Date: Thu, 20 Jan 2005 20:58:51 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: xml languages
References: <csodtv$uhs$1@sea.gmane.org>
 <cc159a4a05012006434e3061f9@mail.gmail.com>
In-Reply-To: <cc159a4a05012006434e3061f9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Peter Hunsberger wrote:
> On Thu, 20 Jan 2005 15:07:25 +0100, BURGHARD �ric
> <eric.burghard@systheo.com> wrote:
<snip/>
>>So is there any plan to add an xslt2.0 generator. Think about a generator
>>which add some context variables (like $cocoon), or give access to
>>protocols (like cocoon:/) inside in your template.

There is such a generator (TraxGenerator) in scratchpad. Don't know how 
well it works. Nothing special is needed for XSLT 2.0, it uses AFAIK the 
same interface, javax.xml.transform, as XSLT 1.0.

> You can already do more-or-less exactly that: just aggregate some
> generators (like the request generator) and feed them to Saxon 8
> (though we use Saxon 7) as a transformer step to apply whatever
> transforms you want.   If you want to use XSLT 2 then use it.
> 
> What many people seem to want is a template language other than XSLT. 
> Personally, I agree that that seems to be re-inventing the wheel, but
> open source communities seem to like constant mutant evolution...

The problem with using XSLT as template language is that it is hard to 
get pull access to Java beans. You can of course serialize your Java 
object to SAX with e.g. Castor or Betwixt in a generator or a source. 
But that soon becomes expensive if you just want to access a little data 
from a large Java object.

What you need is some kind of lazy DOM adapter for the Java beans, that 
only access the parts of the bean that correspond to the parts of the 
DOM that is accessed by the XSLT processor. There is such a DOM adapter 
(o.a.c.components.jxdom.DocumentAdapter) in scratchpad. Don't know about 
the quality of that either. Chris Oliver wrote the TraxGenerator and the 
DocumentAdapter during the "In search of the perfect template language" 
thread that I cited in my previous mail. But he lost his belief in that 
approach and wrote JXTG instead.

I also spent consideral time in refactoring Betwixt to be able to become 
a lazy DOMAdapter. But didn't have time to finish it.

My current view is that it would be nice to be able to use XQuery or 
XSLT 2.0 on Java bean structure, but that it require considerable work 
to make it work well with current implementations. And I don't feel that 
itch anymore.

/Daniel