Skip to main content

Alternative to XUL and XAML

5 replies [Last post]
smiley
Offline
Joined: 2003-06-23

Qt3 Designer is a powerful GUI editor/builder that generates UI descriptions in XML. Script code can then load the XML, which will instantiate and display the components, which can be invoked via DOM style methods. It's simple and elegant and completely seperates presentation from code. Java needs something like this. Code generators are not the way to go. JDNC is overly complex. Keep it simple....

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
xamjadmin
Offline
Joined: 2005-05-29

XAMJ (http://html.xamjwg.org ) is specifically designed as a Java-based alternative to XAML.

talios
Offline
Joined: 2003-06-10

Why an *alternative* to XUL? Theres already several Java implementations available. However, that being said, Both Netbeans and IntelliJ IDEA both have XML layout descripters which are imcompatible, and ultimately serve the same basic function as XUL. What would be good to see is a common *standard* which everyone can implement.

Then you could load up the same GUI definition in IDEA, JBuilder, Netbeans, notepad, and know it's all going to work. One of the biggest complaints I've seen with IntelliJ's approach is that it *only* works with IntelliJ, although that's more their approach to byte-modification for the SWING implementation code.

denisw
Offline
Joined: 2005-01-03

Because NetBeans has the best contact to Sun, it would be the best to make a standard (XML-based) format on top of the NetBeans format. Maybe those files should also be compilable, allowing developers to add inline code, maybe like this:

...

chandra
Offline
Joined: 2003-06-12

Isn't JSR 57 is supposed to do achieve the same efffect? One of the goal of the JSR so that the IDE vendors could interoperate. I wonder why at least Netbeans doesn't use it.

denisw
Offline
Joined: 2005-01-03

Well, I think it's because the JavaBeans long-time persistence per XML is a bit limited; for instance, it can't save key accelrators (because they aren't Beans). With a language especially designed for UI purposes (with JavaBean embedding support, naturally), such things could be done with no problem. And as I said, code could be embedded in such files, which would make event handling pretty comfortable.

Anyway, have you ever selected a component in the NetBeans form editor and looked in the tab "Code Generation" in the property editor? Check it out.