Java XUL Redux. Patrick has some thoughts about my Java XUL post earlier:
I wonder if a java XUL implementation is a good idea.
What this would bring you is native use of java classes from XUL, which would be cool but a double edged sword: XUL is only one piece of the Mozilla architecture puzzle. The real power of the approach resides in the component model, XPCOM, and the bindings it allows from components to javascript.
If you only implement XUL and not XPCOM, the XUL apps created this way would not be portable to other XUL implementations, namely Mozilla.
The right thing to do I think is to work on the java-XPCOM interface to make the java constructs easily accessible from XUL using XUL's architecture, based on XPCOM. I wonder if it's not done already. Haven't look at that in years :-)
But if you want to go ahead anyway with XUL in java, the best implementation strategy would be to make a Jelly module, Jelly:XUL, like Jelly:Swing.
What's the deal with Jelly:Swing anyways? (and why isn't it Jelly.Swing, are we now using Perl or something?) Is Jelly Swing a macro that produces Swing code that I then compile, or is it a library that I include in my project and it creates the Swing UI at runtime? I don't really grok Jelly at all in this context (sorry James).
JellySwing is a Jelly library that allows you to create Swing user interfaces using XML markup. It is similar in some ways to things like XUL though unlike XUL, JellySwing does not abstract away Swing, you still have access to the real underlying Swing widgets. Also unlike XUL, JellySwing does not require you to turn your models into RDF - JellySwing can work with real Java Beans, XML or traditional Swing models.
Just plug your existing beans, Swing models or Swing Actions right into the Swing widgets - no need to turn everything into RDF.
Maybe this small example or this larger example might help give you an idea of what JellySwing is like.
Since JellySwing is just XML, it should be pretty easy to generate JellySwing markup from XUL using, say, XSLT. Also since JellySwing is just a Jelly script, you can reuse all the other Jelly stuff, like Ant tasks, SOAP, Velocity-like expression language, XPath & XSLT support etc.
Anyways, I was thinking about XUL because it's becoming a standard for describing the UI using XML.
Agreed. The weakness is that XUL typically assumes that data is always specified in RDF. XML is a text markup language syntax. RDF is a loglcal model.
I still don't grok why XUL can't just be based on XML, which is way more common and reusable, then just use XPath to extract bits of information from documents.
-Russ [Russell Beattie Notebook]
1:48:04 PM
|
|