GUI creation: XML versus programmatic

Recently I have been messing around with the Glade interface designer, a rapid application development tool that allows you to create full GTK+ user interfaces very easily. The neat thing about this tool is that it saves the GUI as an XML document, which is then hooked into your code through various language specific ‘sketchers’. These sketchers read in the XML and generate the corresponding ‘native’ code interfaces – often at runtime. There seems to be a big push toward these types of XML-based user interface solutions, Microsoft is pushing XMAL through its Windows Presentation Foundation technology as just one example, and it got me thinking: is this really the best way to go?

Pros

XML offers a number of unique and interesting benefits when compared to the classic programmatic style of user interface creation. For one it represents a true separation of the “view” from the logic of the application. This is incredibly important to a long-term modular design. In addition, by storing the user interface in a file external to the application itself, it allows for complete GUI changes just by updating the single XML file – you don’t even need to recompile the code! This is a huge benefit when testing how users interact with various interface designs or changes and makes A-B testing a snap. Similarly if you want to have various custom front-ends to the same application, say a basic user interface as well as an administrator interface, you can simply distribute your application with two different GUI files. Finally, and most importantly, XML is completely language independent. Thinking about changing your application code base from C to Python? No need to re-write your GUI. This in turn leads to better GUI-specific development tools (like Glade) that aren’t constrained by any language’s particular quirks. The flexibility of XML is where this approach really shines.

Cons

Depending on how it is used XML can have not only a performance impact but also a security one as well. Both of these are especially prevalent when using external GUI files. For instance, a program that loads the GUI from an external file must first read and parse said file every single time the application starts. This is an operation that would otherwise have been avoided by using a pre-compiled programmatic GUI. Next while the ability to completely swap out the GUI without re-compiling the code is pretty cool it can also lead to some… unintended consequences. Take this bit of Glade XML as an example:

<widget id=”myWindow”>
<signal name=”destroy” handler=”on_myWindow_destroy”/>
<widget id=”myWindow”>
This snippet of GUI XML tells the sketcher to create a a widget called “myWindow” which emits a “destroy” signal that should be handled by a function called “on_myWindow_destroy”. All seems fine… until some mischievous individual goes and changes either the signal or the handler (or both!). Now your debugged and polished program is doing things you absolutely did not expect. I will however take this moment to point out that at least in the case of GtkBuilder (a sketcher that you can use with Glade) you do not always have to load the XML from an external file. Instead you could embed the XML string inside your program if you don’t want people messing around with it.

Conclusion

While there are some definite trade-offs to using XML I kind of like the direction it’s taking overall application design. So long as you adhere to safe programming techniques I see no real disadvantage with using XML as a definition language for your application’s intricate GUI. Just be sure to validate the XML, at the very least, before allowing your application to run with it. There’s a reason why god invented digital signatures 😉

One thought on “GUI creation: XML versus programmatic

  1. Bill Schauweker

    0. No date, so maybe I am reactimg to a dead posting.

    1. The main “con” that I see is that
    with XML views you now need to learn and read three languages instead of one:
    o your coding language
    o XML – nice for parsers to read, absolutely awful for humans
    o the schema for the GUI – probably not published anywhere

    2. I believe all of those portability/flexibility benefits are theoretical/ephemeral, and are never realized when writing real software.

Comments are closed.