XUL Titan Interview With R.J. Keller (of MozCreater XUL Parser fame)

Hello,

    Welcome back to the XUL Titan Interview series. Today let's  
welcome MozCreater XUL Parser project lead R.J. Keller.

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

R.J. Keller: My name is R.J. Keller and I work as web coordinator of  
TRF Environmental Inc. My primary expertise is in HTML, CSS, PHP, ASP,
MySQL and Java programming (although I tend to do some C# and Visual  
Basic programming from time to time).

My main work on Mozilla includes being former module owner of the  
Help Systems module, the creation of the Firefox Help Viewer API, and
coordinating development around it. After my resignation as module  
owner, I now do general patch work on Firefox and Mozilla Suite when I
have time.

Q: How did you get started on the MozCreator XulParser? Did you look  
into any existing open source XUL parsers in Java before starting  
work on the MozCreator XulParser? Can you tell us a little bit about  
the MozCreator XulParser's history?

R.J. Keller: The MozCreator XUL Parser came about when we wanted the  
entire GUI to
be written in XUL but with the back-end code written in Java. We  
looked at several ways to possibly create a bridge between Mozilla and
Java but few of them worked or were stable enough for our needs.

After that, we decided to look at XUL parsers written in Java. The  
issue with those was that they were difficult to use and didn't really
suit the Java programmer well. We needed a compact and easy-to-use  
solution. Swing turned out to be a nice GUI platform to build a XUL
parser on top of. We did run into some issues where some core Java  
GUI features weren't available, so we created a XUL add-on called  
JXUL to
get some of those features available through out XUL interface. The  
language ended up being very nice to work with considering we had all
of the Java language features in an easy-to-use XML format with  
little performance hit. It's also very easy to make a GUI class use  
XUL, by
simply running the code "new XulFrame("C:\myFile.xul")", you have a  
JFrame object containing all of the GUI elements parsed by the XUL
parser. Or if someone doesn't feel like moving all of their GUI code  
to XUL but just some of it (for example, just the menubar or toolbar),
then you could use the main parser interface to parse only those  
elements.

Q: Can you briefly sketch out XulParser's architecture and its  
building blocks?

R.J. Keller: For usage, you don't need to know much. Basically  
XulFrame takes in a file name through the constructor plus an array  
of Event objects, which basically associates a string with an  
ActionListener so you can set "onclick" fields in your XUL file. The  
only other class you might
need to use is XulParser, which contains functions for getting a JAXP  
XML Document object and using that to parse only certain tags of your
document individually. This is useful if someone wants only the  
<menubar> tag. Usually it's a bit tough to use so using XulFrame will
make your life easier.

Going a bit more deep down inside the parser, we contain abstract  
class GuiParser that can be used to implement any XML-based GUI
language. XulParser is an implementation of this class. GuiParser  
parses tags based on objects of the ITag interface. ITag interface
defines functions that, if you implement yourself, can return a  
component that implements JComponent to use in the parser plus make it
easier for attribute and child tag parsing. Generally to add your own  
tag, it takes very little effort. Basically uniting this interface
anyone could create their own XUL-based language with relatively  
little effort.

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

R.J. Keller: Yes, we do use reflection in some places. Basically what  
happens is you implement the ITag interface. When you implement  
GuiParser, you provide it with an array of class objects for each of  
your ITags. These are used by the GuiParser to create new instances.  
Then once GuiParser creates the new instances, it runs the parse  
method which basically returns the JComponent. Additional information  
like the
GuiParser interface and the parent and main window elements are  
provided through parameters to the parse method.

For attributes, you can extend the IAttributeHolder interface (which  
extends ITag). This provides an extra method called setAttribute that
sends JAXP Attr objects so you can set the swing properties of your  
JComponents. Just using a simple if statement, it checks to see if the
attr equals one of the valid attributes and if so, sets the swing  
element appropriately.

If your tag can contain other elements, you can extend the  
IContainerTag interface, which adds method "add". This takes in a DOM
Element which you can use the GuiParser instance given in the parse  
method to parse this element and add it to your container in about 1
or 2 lines of code depending on the container.

Generally the parser handles all the rest. Overall it's easy to add  
your own tags to XUL if you wanted to or add support to a previously
unsupported tag. What I like about this parser is that, if you run  
into about 10% of tags that are difficult to add support to in the
parser, you can get around that problem easily with little  
performance hit. I've yet to run into a situation where a XUL tag  
couldn't in any
way fit this interface.

Q: Can you tell us some challenges you faced creating XulParser?

R.J. Keller: Getting some of those strange tags to work. <tabpanel>  
was extremely difficult to implement and adding support for the  
<wizard> tag was difficult due to the fact that you couldn't use  
XulFrame. The wizard problem was solved by creating a XulWizard class  
but it's difficult to
make custom window solutions.

At first, the interface was based on ITag only without the extra  
attribute and container interfaces. That caused for a ton of for loops
and if statements. Now that is all handled through the new interfaces  
(IAttributeHolder and IContainerTag) and have saved us a tremendous
amount of time.

The only main challenge we still see now with XulParser is having  
100% perfect XUL be parsed in both Mozilla and XulParser. I'm hoping one
day you could make a complex XUL file work both in Java Swing and  
Mozilla. It's difficult to do that with swing elements, but is
definitely possible.

Also a lack of JavaScript or CSS support has caused huge issues with  
getting styles and scripts to XUL tags. I do have a separate project
I'm working on that integrates Rhino with XulParer.  To fix the CSS  
problem, we've converted CSS attributes to XUL tag attributes, which
is very messy but adds the functionality. I'm planning on adding a  
ICssHolder interface to add some basic CSS support to hopefully
improve support for XUL in XulParser.

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

R.J. Keller: Currently, it can take a basic XUL file and run it in  
swing decently. MozCreator IDE is written entirely in XUL and runs good.

What needs to be done is CSS support. This should fix a ton of bugs  
in the parser and could make a Mozilla/Java cross-XUL platform  
realistic.
We also need to improve our layout of XUL in general to be more  
precise with Mozilla's layout.

A XulWriter is also in the works to be used with MozCreator's GUI  
editor. We'll have more on that at a later date.

Q: Do you have a favorite scripting language for the Java runtime?  
Any plans for adding support for
scripting to XulParser?

R.J. Keller: Yes, as mentioned above, we are planning on adding Rhino  
+ XUL integration to make a full version of the Mozilla Platform  
available
to Java users.

Q: Any plans of supporting different UI toolkits such as SWT, wx4j or  
Java Gnome, for example? Or do you plan to stick to Swing?

R.J. Keller: Actually yes, recent modifications in the XulParser 2.0  
spec make Eclipse SWT support possible. Progress is slow, however,  
due to a lack of contributors.

With the current parser, if someone wanted, they could easily port a  
Java GUI toolkit to XulParser. The issue is getting the manpower for it.

Q: Can you tell us how popular the  MozCreator XulParser is? (e.g.  
How many downloads? Are there any applications/projects using  
XulParser? What's the interest in the Mozilla or in the Java Swing  
community? etc.)

R.J. Keller: It's difficult to track downloads because the project  
has been jumping FTPs often. I do know that the number of downloads  
is way higher than we've expected. Just seeing the surge in bandwidth  
usage on my FTP since MozCreator was added makes me confident that  
we're getting a
large number of downloads. Maybe in the future we might be able to  
give some numbers.

Q: Who else is behind XulParser? Do you work on your own? How much  
time do you spend on XulParser development? How can someone get  
involved in the MozCreator XulParser project?

R.J. Keller: The team is small and we need contributors badly!  
Currently I'm the only programmer but Brant Gurganus and Ryan  
Probosco along with others have made contributions and ideas to the  
specification.

Currently I spend about 3 to 4 hours a week on MozCreator and the XUL  
Parser.

Q: Does the XUL handled by the MozCreator XulParser differ from  
Mozilla's "classic" XUL? Do you envision XulParser to run Mozilla XUL  
apps out-of-the-box?

R.J. Keller: JXUL is the main difference. We definitely hope to have  
any Mozilla XUL file run out of the box on MozCreator.

Q: What's next for the MozCreator XulParser?

R.J. Keller: As for the parser itself, better layout and easier GUI  
parser support.

Thank you R.J. Keller for taking time out to share your thoughts.  
Keep up the great work on the MozCreator XUL Parser project.

Links:
* MozCreator XUL Parser - http://mozcreator.mozdev.org/xulParser.html
* R.J. Keller's Blog - http://rjkeller.blogspot.com/2005/04/xul- 
parser-interview.html


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20