|Overview . Tag Reference . Cheat Sheet . CSS Reference . API Reference . FAQ . History . Upcoming . Gallery . Notes . Powered By Luxor . Contribute . Mailing Lists & Forums . Premium Support . Credits . Glossary . Site Search . The Memphis Sun . Download . Download Luxilla . Download Plugins . Download Contrib . Source . Javadoc . Team . Who's Who . Donate . Luxor @ Sourceforge|
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.
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: 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.
XMLDecoder; forthcoming in Java 1.4
|Hosted by SourceForge||
For questions related to the use of Luxor,
please consult our web pages.
If that fails, the luxor-xul-user mailinglist
Please send comments on our web pages and the development of Luxor to our public luxor-xul-develop mailinglist.
Maintained by Luxor Team
Copyright © 2001, 2002, 2003, 2004, 2005 Luxor Foundation