RE: XSL to Java

[Didier VILLEVALOIS <dv...@techmetrix.net>]

Hi Ricardo,

Thanks. This is interesting!!
I noticed two things:
	- you moved to a pure sax generation model
	- you've changed the Actor/Director managment to a
Component/ComponentManager but I can't see any (big) difference between them
(happy if you explain me :-)

But i think this won't help me too much. Except maybe to integrate my
framework on Cocoon due to the new component managment.

This is because i also need to express markup matching (not just markup
building) in Java.

incomming XML ----( xsl matching - xsl building with java actions )---->
outgoing XML

I'll be happy if this give you ideas about my problem.
Didier.

-----Message d'origine-----
De: Ricardo Rocha [mailto:ricardo@apache.org]
Date: lundi 22 mai 2000 18:12
À: dvillevalois@techmetrix.net
Objet: RE: XSL to Java


Hi Didier,

I have the impression your framework may benefit from the markup
language and code generation infrastructure used for XSP in Cocoon2:
pluggable markup languages, XSLT-based source code generation and
multiple programming language support.

If you want to take a look at it, please check

  ftp://ftp.plenix.com/pub/xsp/xsp.zip
  ftp://ftp.plenix.com/pub/xsp/needed_jars.zip

In absence of documentation (for now) you'd have to
inspect the code. Let me know your impressions if you
decide to do so.

Regards,

Ricardo

Re: XSL to Java

[Ricardo Rocha <ri...@apache.org>]

Didier VILLEVALOIS wrote:
> I noticed two things:
>         - you moved to a pure sax generation model
>         - you've changed the Actor/Director managment to a
> Component/ComponentManager but I can't see any (big) difference between them
> But i think this won't help me too much. Except maybe to integrate my
> framework on Cocoon due to the new component managment.
> This is because i also need to express markup matching (not just markup
> building) in Java.
> 
> incomming XML ----( xsl matching - xsl building with java actions )---->
> outgoing XML

The existing XSP logicsheet preprocessing model provides a solution to
your
requirement: as each tag is recognized, source code is emitted and 
subsequently compiled and executed. This approach gives you the best of
both
worlds: you can inline Java code associated with each "markup
production"
_and_ get it compiled and automatically reloaded as needed.

Alternatively, you may use XSLT extension elements. In this case, as
each "markup production" is recognized by the XSLT processor, an
associated
Java action is invoked that will generate augmented markup (to achieve
this, afaiu, all your Java extension needs to do is returning a DOM Node
object).

Now, if what you want is _embedding_ code in your XSLT stylesheet,
you may want to consider Javascript (Rhino) with Xalan. Xalan extension
support is based on BSF (Bean Scripting Framework) and allows you to
inline Javascript (or other interpreted language) code in your
stylesheet to
implement extension elements/functions.

Note that code inlining in XSLT extensions doesn't work for Java; this
requires a separately pre-compiled class...

Hope this helps,

Ricardo