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 _______________________________________________ xul-announce mailing list xul-announce@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xul-announce

Reply via email to