Welcome back to episode two of the XUL Titan Interview with Dimitri Pissarenko of SwiXml Viewer fame.

Q: How did you get started on swixml-viewer?

Dimitri Pissarenko: Once I wrote a SwixML UI descriptor and wanted to know what it looks like without writing a Java program I started to search the Internet, but didn't find anything, and so I wrote a couple of lines of code.

I think that swixml-viewer is a real alternative to designing UIs on paper.

Q: Can you tell us what swixml-viewer can do today? What works and what needs to be done?

Dimitri Pissarenko: swixml-viewer can display SwixML and Thinlet UIs. There are some serious bugs with respect to Thinlet.

At the moment, swixml-viewer can't display menus.

Concerning the future, I have several ideas about swixml-viewer.

1) Learning and comparison tool

What you can't program, you haven't understood. I want to know how those many XML UI toolkits work in practice and what they can do for me. I think I can learn a lot about them by incorporating the support for them in swixml-viewer.

When someone else wants to know what XML UI toolkit to use, he/she can simply take swixml-viewer, look at the UI descriptor, look at the code, which renders it, and decide what XML UI toolkit he/she likes most.

If users of XML UI toolkits are able to see the differences in UI descriptors and the code clearly, they can make a better decision whether to use XML UI toolkit and if yes, which. This can promote the use of XML UI toolkits.

2) Aspect-oriented UI generator

This idea is much more uncertain. Most of us have certainly heard (or used) the Hibernate framework for persisting Java objects in relational databases. One of the features of Hibernate I like most is the fact that a Java class doesn't need to know that it can be persisted in a relational database. That is, any JavaBean can persisted and not a single line in its code is related to persistence. This is an excellent example of aspect-oriented programming.

Now, perhaps one can automate the creation of UIs for objects in a similar way. As an example of how this might work, see example program Demo2.java. It is analogous to Demo.java, except that now the DemetrixPropertiesHolder is created from a plain old JavaBean. Note that the bean needs not know that it can be displayed as a DemetrixPropertiesHolder.

Q: Do you have a favorite scripting language for the Java runtime? Do you want to see scripting pushed more in SwiXml or do you want to keep the code Java only?

Dimitri Pissarenko: Sometimes I use BeanShell. However, in my opinion scripting should be used only to a limited extent due to testing problems (it is much easier to test Java code than a script).

In my programs, event handling is done in Java. The crucial point about event handling is testability. If it is possible to test event-handling code, I will consider using script-based event handling. At the moment, I use JUnit, JUnitX and Abbot to test my UI-related code. I am satisfied with this "triad".

Again, it depends on the environment. If some programming genius creates a way to use the same UI descriptor in a desktop Java app, on the web and, say, on PalmOS, I definitely will use it (even if testing is difficult).

Q: What's your take on adding CSS support to SwiXml for styling using rules?

Dimitri Pissarenko: In principle, this is a good idea. I think there are situations, in which such styling mechanism can be very elegant (for instance, rendering of UIs for people with special demands, like handicapped people).

Concerning my practical work, I don't think that this is a vital feature without which I can't survive.

Q: What do you think is still missing badly in SwiXml?

Dimitri Pissarenko: Well, nothing :)

I am interested in mechanism, using which one can write one UI and then use it in different environments. In particular, I want to discover how one can create PalmOS-versions of normal Java apps, including UI.

Another thing I am thinking about is using SwixML (or another XML UI framework) on the web. Many people (including me) don't like usual web interfaces.

Q: What's next for swixml-viewer? Any plans for adding alternative XML UI language formats in addition to SwiXml and Thinlet?

Dimitri Pissarenko: I plan to include support for all major XML UI frameworks. And, of course, to test and debug swixml-viewer.

Another thing is integration of swixml-viewer into important desktop environments (Windows Explorer and analogous file managers in KDE or Gnome). I want swixml-viewer to display the contents of an XML UI descriptor by a single click under both Windows and Linux.

Q: Do you have any future plans for SwiXml?

Dimitri Pissarenko: I want to try to use SwixML in web environments and on PalmOS. If current state of SwiXml does not permit it, I will consider extending it.

Thanks Dimitri Pissarenko.

Links:

• SwiXml Viewer @ http://swixml-viewer.sourceforge.net
• Demetrix @ http://demetrix.sourceforge.net
• SwiXml Project @ http://www.swixml.org
• SwiXml Developers Group @ http://groups.yahoo.com/group/swixml