Over the last two weeks, we’ve taken a round trip of XUL. We’ve covered browsing, searching, and navigation. But what about the real-world implications of using UXL? Let’s consider these now.
But No One Uses Mozilla…
Current estimates place Mozilla 1.0+ / Netscape 6.0+ as being the browser of choice for anywhere between 2% and 20% of surfers on the Internet. When AOL finally decides to deliver some version of Netscape to its customers, that number could jump significantly. But you’re right. The majority of the Net uses Internet Explorer, and that’s unlikely to change in the near future.
The question is: do you, as a leading edge Web builder, want to offer your visitors the best possible viewing experience? Do you want opportunities to impress potential customers and show them the possibilities of building “rich” clients that can be deployed online? Learning XUL and demonstrating your flair with it, could bring in that vital lead in these days of tight budgets and stiff competition.
To help you on your way, here’s some practical help from PHP and phpSniff, an excellent PHP project that helps you determine which browser a visitor uses.
<?php
// Browser detection script using PHP Sniff
// http://phpsniff.sourceforge.net
// Set this to the URL for your site
$url='https://www.sitepoint.com/'; // Trailing slash important!
// Include phpsniff code
require_once ('phpsniff-2.1.2/phpSniff.core.php');
require_once ('phpsniff-2.1.2/phpSniff.class.php');
// Instantiate phpSniff
$phpSniff=new phpSniff();
// Get the browser type and version
$browserCode=$phpSniff->property('browser');
$browserVer=$phpSniff->property('maj_ver').$phpSniff->property('min_ver');
// Lookout for Mozilla 1.0+ and Netscape 6.0+
if ( ( $browserCode == 'mz' && $browserVer >= 1.3 )
|| ( $browserCode == 'ns' && $browserVer >= 7 ) ) {
// Redirect them to the xul index for the site
header ( 'Location: '.$url.'index.xul' );
} else {
// Send all other browsers to the normal index page
header ( 'Location: '.$url.'index.html' );
}
?>I’ve used phpSniff version 2.1.2. The above code is on the lookout for Mozilla 1.3+ and Netscape 7.0+. If anyone who arrives at your site uses those browsers, the script will redirect them to index.xul, which is the “XUL enhanced” version of your site.
You could place this code at the top of your home page (e.g. index.php). Be aware that you’ll need to make some further modifications if you plan to use index.php from index.xul with an XUL “browser”, otherwise you’ll be redirecting Mozilla viewers through an infinite loop. And don’t forget to include that .htaccess file I used earlier on, so that you can generate the correct MIME header in index.xul.
The Rise of the Rich Client
HTML, forms and JavaScript are great for your typical Website. But there are always some things that, try as you might, you just can’t do, such as building a page that’s capable of “real time” updates (and I’m not talking meta refresh here), or trying to emulate a desktop application online.
Over recent years, numerous approaches have been made to bring “rich clients” to the Internet.
First we had Java Applets, which benefit from the excellent Java class library. Unfortunately, Swing, Java’s client building library, is notorious slow, and has even given Java itself a reputation for slowness (which isn’t the case). Also, learning Java certainly isn’t something that happens over a weekend…
Next, there’s Flash. Since MX was released, Flash has been getting some serious attention as a good technology for building rich Web clients, and rightly so. Macromedia are promoting Flash as a tool for building the front end to J2EE and .NET applications… But not everything’s great. Flash is delivered in binary format, which can mean a very long wait for your users if you’ve built a large application. Also, it’s difficult to render complex Flash applications using server side technologies such as PHP, Perl, ASP(.NET) and Java. Projects like Ming have made amazing progress, but building a Flash form with PHP is still far more difficult that is building an HTML form.
Along similar lines to Flash, there’s also SVG, a W3 XML standard, which Adobe and the Apache Group have done a lot to make happen. What’s great about SVG is it’s pure XML; that means sending an SVG document to a browser is as fast as any normal web page. Although it’s possible to implement such things as forms in SVG, in the end the big clue is in what SVG stands for: Scalable Vector Graphics. As a markup language, it doesn’t make handy for building the components we expect of a user interface, such as buttons and menus.
XUL is a completely different story. This is a markup that has been designed specifically to build graphical user interfaces. In this article, I’ve only looked at simple examples of how you can accomplish with XUL tasks that Web builders have been battling to get right with DHTML. All you’ve seen here are really just enhancements (which are ultimately (X)HTML) to pages.
But XUL doesn’t stop there — far from it, in fact. XUL is a technology that allows anyone who’s capable of HTML to build complete desktop and/or Web-based applications. Essentially, anything you can do with the Mozilla browser (e.g. open files, edit documents, view images, send email etc.) can be re-used in an XUL application.
Even in these days of dynamic Websites powered by technologies such as PHP, we’re still struggling to build online applications that truly are easy to use. Adding content to a Website should be as easy as editing a Word document — no HTML required. XUL is the technology that can make this happen.
The “magic” is in the XPCom library, which, among other things, provides support for SOAP and XML-RPC, two Web services protocols (see Kevin Yank’s Web Services Demystified for more).
“Launching” an application that acts as a WYSIWYG editor for HTML, and is capable of updating a Website is now a reality. The XUL for that application can be rendered “on the fly” by PHP, then loaded by Mozilla in a matter of seconds. Once it’s running, users can edit text without need to know HTML, then update their site, whereupon the XUL application delivers the content to another PHP script, which acts as a SOAP server. Mozblog is a desktop XUL application that demonstrates this principle, allowing you to update a blog over XML-RPC. Over on O’Reilly you’ll find an excellent article on Using the Mozilla SOAP API, which describes all the technical detail. Be aware that WSDL support in XPCom is still a work in progress, so building XUL SOAP clients is manual labour.
What’s the catch in all this? Speaking frankly (having lost more hair in the pursuit of XUL!), I can say that Mozilla (or whoever) really needs to wake up and start thinking about how things look from the outside.
For security reasons, using the XPCom SOAP API from a JavaScript that has been loaded directly from a Website requires the visitor to give their explicit permission before it can run in their browser. This is a good thing, but it requires developers to digitally sign the JavaScript, so that anyone who’s loading your application can check your credentials before executing it. Fair enough…
Unfortunately, the official explanations of how you must sign your JavaScript read like beer mat doodles and are scattered across multiple sites, some of which look as if they were knocked up in half an hour. And don’t get me started on the README file in the signing tool they recommend, which directs you to this up to date URL.
Perhaps I’ve been spoilt by PHP over the years, with its excellent documentation and amazing community, but why bother putting so much effort into building such a great technology, designed to make developers lives easy, then fall at the final hurdle? Compare that with the excellent job Microsoft has done in promoting ASP.NET and making it a technology which really appeals to its users, and perhaps you can forgive my complaining. This kind of thing reminds me of the days when IBM tried to sell desktop operating systems…
Moaning aside, XUL really is a great technology. Right now it’s got the official “it works” stamp of approval, but the paint still hasn’t dried. XUL has reached a level where it’s definitely worth putting in the effort to learn, but be prepared: there’s still a lot to do to set up resources both for learning XUL, and developing with it. Right now the #1 development tool is the humble text editor, although the Luxor SWT prototype may soon bring XUL to Eclipse, and lead to another alternative to Mozilla as the XUL runtime.
To quote the Mozilla crew themselves:
“In the beginning, there were 3 front ends (FE’s): mac, windows, unix. Each took a suite of developers to maintain. Adding a new feature (even just a button) required 3 engineers to waste at least a day (more often, a week) slaving away until the feature was complete. This had to change.
What if we could be in a world where we could just write the code once? Where non-programmers could design the look and feel of a product using W3C standards instead of C++? Where platform differences could be expressed in stylesheets, not hardcoded with #ifdefs?
Do you like that world? So do we.”
Resources
Creating Applications with Mozilla — a free, online version of O’Reilly’s book covering XUL and XPCom.
XUL Developer Central at Netscape.
XUL Planet — a growing collection of tutorials and resources. The introductory tutorial should help to get to grips with all the important XUL elements.
The XP Toolkit — more examples of XUL.
MozDev.org — Mozilla’s own “Sourceforge” for building XUL applications. Plenty of useful examples here, or even start your own project.
Part 1, Part 2 and Part 3 of IBM’s Python and XPCom tutorial series on implementing “code behind” logic for XUL applications. Quote: “Implementation so simple it’s scary…”
An introduction to XPCOM — a fairly technical article series looking at the XPCom library.
If you use Linux, there’s a “bridge” being built between XUL and Glade, called MozGlade, which should make it easier to build XUL applications.
Harry FuecksHarry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.
