Luxor: Tech Talk, December 2001

Gerald Bauer (Luxor Project Leader) answers Jeff Duska (President of the Upstate Java Users Group)'s questions about the Luxor XML User Interface Language (XUL) Toolkit.

Q: You appear to be stating that using XUL to develop rich-client UI will reduce effort and cost, i.e. we will be more productive. I am correct?

The goal of XUL is making cross-platform user interfaces as easy to built as web pages.

Q: Do you see Luxor XUL as being a client toolkit only?

I don't like the word client. Luxor is a toolkit for desktop apps that includes clients as well as servers in a single app.

Q: Why not suport the JavaBean Persistance XML Schema?

XUL is not tied to Swing, in the future gooey engines might be available for SWT, Mozilla Gecko, QT, GTK+ and more.

XUL is not tied to Java, in the future engines might be availabe for C# and other languages.

Look at Bluestone XwingML, a dead early XUL dialect a la JavaBean XML Schema Persistance, and you will see that dumping the state of a bean 1:1 in XML is a dead end.

Q: Next, it would appear to me that this provides developers with a solution to the whole Swing/Native/SWT/GUI Flavor of the Month. The project should provide the interface which the developer programs to. Then based on a configuration file, the correct renderer is loaded. Thus, I could be using SWT, Swing or Java Qt to create the UI interface components, but I don't care. This means other renderers could be created, for example a braile display, Gecko, or HTML renderer.

That's a goal.

Q: Where I get lost is the whole concept of the Java Client Pages. I don't see why I would limit my self to using JSP/Velocity Taglib for a rich-client UI. If I could do the UI in JSP/Velocity, I would think it would be smarter to use a server. Thus, this leads to my confusion of why we need to have a full-fledge HTTP Server as part of the project.

Luxor XUL doesn't use JSP but uses Velocity instead plus XSL/T in the near future. You are not limited to Velocity or XSL/T. You can mix XUL parts with your own hard-coded Java gooey parts.

Luxor XUL does't include a full-fledged HTTP server, instead it uses a ultra light-weight, multi-threaded personal web server that services a single app, but not thousand users at once.

Q: I don't like this solution, because it seems more convoluted then our mess of today. Why should a developer move from using JBuilder, NetBeans/Forte or WebGain GUI Designer to a mixture of XUL, XHTML and Java? You mention using the Gecko, so does this mean we'll have to include JavaScript in this mess also.

I don't call XUL, XHTML, Velocity, XSL/T, Java, CSS, JavaScript and more a mess, instead I call it open standards offering choice and freedom.

If you don't like freedom and choice use Visual .Net instead. It's up to you.

Q: I'm also lost on how a client application development tool is a portal? I wasn't clear on how the whole Jetspeed project fits within Luxor.

Luxor includes a portal engine. Portals are nothing more than web pages mixing static XHTML content with dynamic HTML content from portlets (also known as HTML controls or HTML pagelets that are basically like servlets, but return HTML snippets instead of complete HTML pages)

Luxor doesn't include Jetspeed, instead it includes a light-weight portal engine.

Q: Next, is XUL rich enough? It has been sometime since I reviewed XUL. I looked at it back when I was playing with FreeBuilder and Korfe. At that point you couldn't describe a complex UI. It was also tied to the JavaScript language. Has this changed?

XUL is not tied to JavaScript and is rich enough. As a fall back you can always mix it with your hand-coded Java gooey parts.

Q: Lastly, is XUL solid enough that we can depend on it. As mentioned above, I say XUL's DTD has changed a lot, so developers had to rewrite code that they were not supposed to touch.

Change happens and nothing prepares you better than having your gooey in XML than tied to one vendor's GUI API in a single language be it Java, C# or whatever else comes along.

If the DTD/schema changes you can use XSL/T to automatically convert old XUL files to new ones.

• Apache Velocity - (http://jakarta.apache.org/velocity )- embeddable open-source template engine not tied to a web server
• Apache Jetspeed - (http://jakarta.apache.org/jetspeed ) - open-source portal server (pionieerd portlets)
• Eclipse SWT - Standard Widget Toolkit - (http://www.eclipse.org ) - alternative open-source cross-plattfrom Java widget toolkit available for Linux and Windows
• Trolltech QT - (http://doc.trolltech.com ) - open-source cross-plattform C++ widget toolkit used for KDE Desktop available for Linux, Windows, and Mac OS X
• GTK+ - Gimp Toolkit - (http://www.gtk.org ) - open-source cross-plattfrom widget toolkit used for Gnome Desktop available for Linux and Windows
• Mozilla Gecko - (http://www.mozilla.org/newlayout ) - open-source, cross-plattform, embeddable, small, fast, standards-based HTML layout engine designed for speed and portability
• Java Bean Persistance XML Schema - (http://java.sun.com/products/jfc/tsc/articles/persistence3/index.html ) - dump or read a bean's state in XML using XMLEncoder and XMLDecoder; forthcoming in Java 1.4