Rich Internet for Everyone (RICHIE) Network: United XAML - XUL Alliance - XUL News - XUL Forum - The Richmond Post - RichCon 2005
The Richmond Post Logo
Chronicle of the Xul Revolution
« Thinlet XUL Titan Interview (Kate Rhodes of Caterpillar fame) - Part I | Main | SwiXml Titan Interview (Kate Rhodes of Caterpillar fame) - Part II »
XUL Titan Interview: Son To (of Sulu fame) - Part I
posted by Gerald Bauer on June 14, 2004

Welcome back to the XUL Titan Interview series. Today let's welcome Sulu mastermind Son To.

Q: Can you tell us a little bit about yourself?

Son To: I grew up in Philadelphia, PA and still currently live there. I've been programming computers since the age of 10 in a dozen different languages. I graduated from the University of Pennsylvania's Wharton School in 2000. I'm currently an independent contractor working mostly with Java related technologies. I also teach c#, java, python, linux classes. I've been an avid linux user since my high school years (circa 1994). In a previous life, I was also a unix sysadmin.

I've been a Java programmer since 1995 and use it primarily for work, but I make an effort to learn a new language each year because although all languages are isomorphic in the sense that they're all turing complete, each languages has a unique way of solving a given problem in different way. This year my new language is Prolog ... it has help me understand semantic web RDF.

Q: How did you stumble onto XUL?

Son To: I stumbled upon XUL via Mozilla around 1999. I was really excited about XUL when I heard of it because I like the simplicity of html for quickly creating GUI forms, but dislike the contortions one has to go through to create a desktop like GUI.

I think the Mozilla Application Object Model (AOM) is very elegant. Mozilla views the application GUI as a tree. Manipulating that tree manipulates the GUI.

I think XML is abused by falling into the "Golden Hammer" antipattern which says if all you have is a hammer everything looks like a nail. Look at apache jelly for example. Executable XML is a bad idea.

However, Mozilla's use of XML to represent a GUI is a good idea. Since XML can be represented as a tree structure, it is great for representing a GUI because the relationships between the components in a GUI can be represented well with a tree. Since DOM is a standard way of representing and manipulating the XML tree, it provides a uniform and simple way to manipulate a GUI. Since the GUI can be respresented as a DOM XML tree, programmers can use XPath to navigate the GUI. Mozilla doesn't have support for XPath yet, but Sulu does.

In writing swing GUI, often times I would have a component within containers within containers within containers so its easier to layout but navigating the object model to get to that component can be a real pain. This can now be done easily and elegantly with XPath.

Q: How did you get started on Sulu?

Son To: Around 2001, I prototyped a POS (Point Of Sale) system using Mozilla XUL. The Mozilla XUL gui connected to the backend using jabber instant messaging. Writing socket code in C++/javascript to connect to jabber server was a real pain. Then I discovered PyXPCOM which allowed me to write the same code faster and more elegantly in python. However PyXPCOM would break with a new Mozilla release and getting it to work is a black art.

The Mozilla blackwood project promised Java support on par with JavaScript, but that never happened and the project seem to have died.

I wanted Mozilla XUL, but I did not want to write business logic code in C++ or JavaScript. So in septermber 2003, I decided to write an Mozilla XUL rendering engine that will allow writing business logic in java and python.

Q: Can you tell us some challenges you faced building Sulu using Java and Swing?

Son To: The implementation strategy I choose was to create org.jdom.Element Adapter (aka Wrapper) for Swing components. Look at net.openbx.sulu.swing.XulSwingAdapter.

The idea behind this use of the Adapter pattern is that a client manipulates a Swing component using the org.jdom.Element API. Manipulating an org.jdom.Element will result in manipulation of the corresponding Swing component. This technique worked well when there's a one to one mapping between Mozilla XUL tags and Swing components for example <button> and JButton.

Not all xul tags map one to one to Swing components, for example <splitter> and JSplitPane. Mozilla treats the <splitter> as a component just like <button> but JSplitPane is not just a component, it's also a container.

Q: Can you tell us how you handle the mapping from XML tags/attributes to Swing classses/properties? Do you use reflection? Do you use hand-coded glue code?

Son To: The mapping from xul tags to XulSwingAdapter classes is hardcoded in net.openbx.sulu.swing.XulSwingAdapterFactory although the mapping should be refactored into a property file.

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

Son To: You can write fairly complex GUI, but since there isn't a one to one mapping from Mozilla XUL to Swing components, not all tags are compatible with Mozilla... for example <table> ... Mozilla XUL doesn't have a <table> tag. To make it compatible with Mozilla, instead of delegating to swing components, sulu will have to render its own components using Java2D for example.

The goal is 100% Mozilla xul compatibility, but Sulu isn't there yet. There's lot to be done like RDF.

Thanks Son To. Check back next week for the second part of the XUL Titan interview with Son To discussing why Son chose Python for scripting, what's the state of CSS support, how Sulu differs from alternative XUL toolkits for Java, what the future holds for Sulu and much much more.

Links:

SourceForge Logo Please send comments on our web pages to our public xul-talk mailinglist or to a member of our web team. Copyright © 2003, 2004, 2005 Open XUL Alliance