[Kde-java] XSLT to generate Java sources

[Marco Ladermann]

Am Montag, 26. Mai 2003 13:19 schrieb Richard Dale:
> On Sunday 25 May 2003 10:11, Marco Ladermann wrote:

<snip/>

> > I hope this stylesheets are of some use for some people out there and 
> > will help to popularize the java-bindings.
> >
> > Any comments to improve the stylesheets are welcome!
>
> I've just been having a look through the juic stylesheets - this is really
> interesting stuff!  And good it works with both xalan and xsltproc and
> doesn't need extensions.

Not at all. The stylesheets need some of the exslt Extensions 
(http://exslt.org). In particular the "exsl:node-set" function and the 
"function" and "result" extension elements. The former is essential but the 
latter can be removed in favor of pure named templates (with a lot more 
variables and call-templates). This is one reason that the stylesheets work 
only with the latest xalan, due to to some bugs in earlier implementations of 
the function element.

My first idea was to give the new XSLT 2.0 a chance, but saxon 7.x is the only 
(exeprimental) implementation of the upcoming standard. So I decided to made 
a compromise and used the exslt extensions, which makes XSLT programming a 
little bit more concise.

>
> One minor thing - the <classname>EventHandling.java classes are no longer
> generated - the event handling methods are generated as normal java methods
> in the classes now, so those interfaces aren't needed anymore. The virtual
> method callbacks for Widget::polish() aren't implemented yet, I don't know
> if that causes a big problem.

I will have a look at it next weekend. My approach was to take the UI files of 
the designer examples directory and look what uic generates. This try and 
error procedure was necessary due to the missing of any precise documentation 
for the XML file format.

> When you first mentioned that you were using XSLT with the uic, I didn't
> really know in detail what XSLT was all about. But since then I've got a
> few books and tried it out, and I think that the whole QtJava bindings can
> be generated that way. Just need to parse the headers with the kalyptus,
> and write out .xml files for each C++ class. Or alternatively there is some
> discussion on the kde-bindings list about extracting .xml C++ class info
> directly from gcc compiled code, without needing to parse the headers.
>
> Then it might be possible to derive a juic stylesheet like 'QtClasses.xml'
> which lists all the Qt and KDE classnames, from the same XML database that
> would be used as the input to the main QtJava bindings generation.
>

The main advantage of this would be, that the C++ parsing is decoupled from 
the binding generation. I tried some times ago to understand what kalyptus 
does, but I missed it :(. To have a xml file describing the Qt interface 
would be a great improvement!

> Anyway I can study how your code works for now, and try it out - it looks
> like an ideal way to get up to speed with this XSLT stuff..

I should write some documentation for the stylesheets and I will do it soon, 
by replacing the xml comments with xml tags in a special namespace (something 
like
<doc:template name="xyz">
	<doc:param name="v"/> bla bla </doc:param>
	etc.
</doc:template>
and then use XSLT on the stylesheets itself to generate the documentation.

Marco