Slashdot Mirror
Rapid Application Development with Mozilla
The Basics Rapid Application Development with Mozilla (hereafter RADM) centers on XUL, Mozilla's XML dialect for describing GUIs. Other Mozilla components, like XBL and RDF, are described mainly in terms of how they plug into XUL. Each chapter presents and explains a component, then shows it in action by using it in an example application (a web-page annotator) developed throughout the book. Chapter conclusions take the form of debugging hints; as McFarlane ruefully notes, most errors cause Mozilla to silently do nothing, making debugging a chore.
The first half of RADM covers basic XUL use -- the usual complement of widgets with CSS to style them and JavaScript to manipulate them. McFarlane does assume previous exposure to basic HTML, JavaScript, and CSS, but extensive experience isn't required. At each step McFarlane does a good job explaining what's similar to HTML (e.g. most DOM stuff) and what isn't (e.g. the layout model). A few components have no real analog in the HTML model, like Mozilla's command dispatch system, so they're presented from the ground up.
The Back EndThe second half of the book leans more toward the back end: using RDF for registries and template data; piping data into XUL with overlays, templates, and XBL; using and implementing XPCOM components; and deploying applications built on Mozilla.
McFarlane's RDF tutorial is one of the best I've seen. He starts off on the right foot by introducing things in terms of a directed graph, with lots of examples and diagrams. Only after eighteen pages of that does he introduce the RDF/XML syntax. His explanation of RDF/XML is unusually lucid, quite a feat considering how hairy RDF/XML gets. (Disclaimer: I've had past experience with RDF, so I wasn't reading this as a beginner -- in other words, YMMV.)
In the succeeding chapters, RDF is applied within the various Mozilla arenas, like XUL overlays and package installation, where it's used to store config information. The centerpiece of RDF in Mozilla, though, is in its use to create data-driven XUL files through XUL templates.
The chapter on templates runs to sixty-plus pages, and it's worth it. McFarlane covers things I haven't seen covered anywhere else. For instance, he describes the algorithm the RDF query engine uses to evaluate queries, so that you can better understand what kind of queries you can construct. This is crucial information because the query syntax allows a lot of queries that are logically reasonable, but won't actually work.
This points to a strength of RADM: McFarlane doesn't hesitate to criticize Mozilla where necessary. Throughout the book, he flags incomplete features, buggy implementations, and other gotchas, such as security restrictions surrounding RDF that make it all but useless for remote scenarios.
(Incidentally, McFarlane explicitly disclaims coverage of Phoenix/Firebird/Firefox, sticking to Mozilla 1.4, but in practice everything I've tried has worked fine in Firefox 0.8.)
Two Out Of Three Ain't BadSo, does RADM manage to accomplish its goals of being a conceptual overview, tutorial, and reference? I'd give it two out of three.
As a conceptual overview, RADM shines. McFarlane is at his best when comparing and contrasting closely related components, like overlays, templates, and XBL, all of which extend XUL but do it in different ways. I was left with a good picture of what can and can't be done in Mozilla.
As a tutorial, RADM is solidly useful. The example-application sections cover a surprisingly large amount of ground -- more than enough to get a developer new to Mozilla up and running. McFarlane chose a good subset to present as examples; still, all of his clear writing can't paper over the fact that Mozilla is really complicated, not just internally, but in the interface it presents to developers using it as a platform.
As a reference, RADM stumbles. The index is slim -- a mere eighteen pages after 752 pages of content -- which makes small chunks of information hard to find. This is mitigated by a detailed and well-organized table of contents. After a few weeks of use, I find myself turning to the contents first, and only trying the index if I have to.
Fundamentally, though, RADM isn't really a reference book, and definitely not a "quick reference." You'd be better off using a good site like XULPlanet for quick what-arguments-does-that-method-take checks, and reserving RADM for in-depth explanations.
ConclusionRADM is published in Bruce Perens' Open Source Series at Prentice Hall under the Open Publication License. After a few months of letting the book sell on its own, they'll post the PDF of the entire book online. Is it worth buying in print? Given that it's more of a sit-down-and-read book than a quick-reference guide, I'd say so.
If you're considering Mozilla as a platform, I'd recommend RADM for its reasonable balance that shows Mozilla's strengths and weaknesses. If you're already sold on Mozilla and just want to wrap your head around it and start building an app on it, RADM is the book for you.
You can purchase Rapid Application Development with Mozilla from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
Here
I think too much is made of Qt when compared with Gtk/Glade (Glade being the XML format for describing Gtk interfaces, not just a GUI GUI tool).
The Glade XML format is kind of strange (it looks like XML described in XML; a pointless scheme), but Glade simplifies GUI development to a point that I have yet to see anyone improve on, in terms of simplicity (I've worked with Tk, regular Gtk, wxWindows, and web-based applications).
True story.
Komodo, perhaps?
From the Features page:
Built on Mozilla
Komodo is built on the Mozilla platform. Portions of Komodo were created using source code governed by the Netscape Public License (NPL) and the Mozilla Public License (MPL). The source code for the portions of Netscape 6 governed by the NPL and MPL is available from under those licenses.
How about the Activestate IDE, Komodo?
This sounds very much like it actually delivers what Creating Applications With Mozilla promised. After reading CAwM first 3 chapters, having them completely confuse all the various issues in my mind, a wrote this review. To give Boswell credit, he emailed me with some pointers to resources that helped get me over the hump, but that doesn't excuse O'Reilly's editorship from their usually excellent job of encouraging authors to make their work accessable as well as detailed.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Here's the source RTF document in a zip file. That's Rich Text File, not the usual acronym :-)
So, having established that it really is Open Source, I do encourage you to buy the book.
Thanks
Bruce
Bruce Perens.
The book has already had its few months in paper-only format, and is available to download (along with a number of other books in the series) at InformIT
Then surely XUL improves on Glade, by being not so strange. On the otherhand, XUL's reliance on Javascript might give the lead back to Glade/GTK.
Check the XUL specification. It uses http://www.mozilla.org/keymaster/gatekeeper/there. is.only.xul
which is a Ghostbusters reference.
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
Bruce
Bruce Perens.
Sorry, but FileZilla runs as a native Win32 app. It doesn't have anything to do with Mozilla.
XUL is not an API in the same way that Qt and GTK (I infer that these are examples of "others") are. Rather, it's a standard for describing UI with XML. So, if you have a requirement that you might need to port your application another platform at some point, XUL might not be a bad choice.
In this world nothing is certain but death, taxes and flawed car analogies.
He was talking about platforms, not toolkits. Platforms provide more than just GUI libraries -- they're application frameworks and component services.
OK, you won't use it, but I did recently write a Mozilla application for MagPortal.com to allow our editors to work remotely. We are a Linux shop and our editors mostly use Windows, so it had to be cross-platform. Mozilla/XUL was used for the client application to provide a nice GUI interface (more sophisticated than what you could achieve with normal HTML -- uses widgets like <tree> and transfers data in a way that reduces latency for the user) that transfers XML back and forth across the Internet to the web server for storage. It works very nicely and is quite professional. I am somewhat surprised that you don't hear more noise about companies building custom applications like this with Mozilla.
McFarlane's book was my primary reference for the project. It is a very useful book, but I do agree with the reviewer that the index needs some work. Additionally, make sure you keep an eye on the errata page. I was a bit disappointed that the book didn't talk about how to parse generic XML in your application (look at the parseFromString() member function of DOMParser).
You obviously have no idea what rapid development means. It does not equal "cowboy coding with no testing". It means minimizing bureacratic overhead; iterative approach, building of prototypes. Iterative approach and prototyping make it LESS likely bugs stay there very long -- instead of having month-long painful integration infernon at the end of 2-year long waterfall death march, integration is done much more often, prototypes are reviewed, code is refactored, and code quality remains high.
If you check out OEone's HomeBase Linux distro you'll see what can be done with Mozilla. Everything in it runs with Mozilla as the desktop interface. It's increadably slick and easy to use.
--
If I actually could spell I'd have spelled it right in the first place.
It's a persisted GObject tree. libglade reads the XML which maps pretty much directly to constructing a tree of GObjects and setting their properties and signals. The reason it looks like XML describing XML is because it's describing a tree of attributed nodes, but with callbacks - ie they *are* similar, but at the same time they are actually quite different.
The Glade XML format isn't designed to be written by hand, whereas XUL is. To be honest, I'd rather have a decent UI builder....
"Looking and behaving better" is partly a matter of what you are used to, and also a reflection on the poor quality of many Java UIs, which is more a reflection on the apps themselves rather than the platform (there are exceptions, demonstrating that Java is capable of being better). If you could have an app that looked and acted exactly the same on all desktop machines, and appropriately differently on palmtop devices (but the same across all such devices), would that be enough to make you want to avoid duplicating all those presentation layers? (I think you underestimate the amount of work involved in producing a good presentation layer, BTW).
1) Get GTK 2.2.4-2 from http://dropline.net/gtk/. It includes my native Win32 theme.
3 ) Uninstall any old GTK, Gaim, and Gimps, just to be safe.
2) Get Gimp 2.0 from http://www2.arnes.si/~sopjsimo/gimp/stable.html
4) Install GTK 2.2.4-2
5) Open regedit
6) Change HKEY_CURRENT_USER/Software/GTK/2.0/Version to read "2.2.4-20040124"
7) Change HKEY_LOCAL_MACHINE/Software/GTK/2.0/Version to read "2.2.4-20040124"
8) Install the Gimp
9) Enjoy
Firefox and Thunderbird use a newer XUL toolkit than Seamonkey, but they all use XUL.
The shareholder is always right.
timothy got it exactly right. This is a very nice overview and collection of tutorials. It is definitely not designed as a reference, and that is the biggest thing missing for Mozilla/XUL right now. (For now, your best bet is a combination of the book + xulplanet.com, but XULPlanet's reference is just a little too terse to be useful on many things). IMHO to really document Mozilla in a useful way would take at least a couple 1000-page books.
... sockets. In Javascript. Crazy... So, trying to keep in mind Eric Raymond's "Art of Unix Programming", I pulled together a few small daemons using PHP in CLI mode to handle back-end stuff, and used socket_select() to set up a message-dispatching system, keeping things nice and simple and "textual" (as ESR puts it) between PHP and Mozilla. Used the ":" as a delimiter, escaped text going in both directions using standard urlencoding (PHP and Javascript talk that language nicely). Asychronous notification... fun stuff. I can use PHP to call any Javascript method in Mozilla, and vice-versa with PHP, using variable function execution.
Anyway, reading this book did provide me a great leap forward in my first large Mozilla app. For anyone who doubts whether serious work can be done in Mozilla, I will say... yes, but not with Mozilla alone. Obviously, Mozilla is intended as a GUI framework, so to accomplish serious work, you still need some system-level stuff to happen. My biggest quest in developing a kiosk-based app for Linux was how to integrate the two:
1. How to do this is not as readily apparent as I had thought. Of course, every web app developer's first thought would be to use Apache/PHP and basically treat the thing as a web app. But that ignores 90% of the true capability of Mozilla, so even though that was my home turf, I rejected that concept.
2. I thought maybe I would dig into that incredibly large pile of interfaces that makes up XPCOM, and see if I could play with the Python or Perl implementations, but my project was too much of a RAD situation to allow for that kind of time.
3. I thought maybe I could use MozPHP, which embeds a PHP intepreter in Mozilla. Turns out that it is near impossible to actually get it to work, and it really plunks you right back in the same old dynamic-document-building territory as the HTTP-based solution would. (In other words, you are using PHP to constantly re-write XUL content, which in the end can be very counter-productive and performance-intensive for the front end)
4. Finally, I realized that with JSlib (http://jslib.mozdev.org), I could use
Performance? Performance is great. Remember, these are daemons, so I am not continually invoking the PHP interpeter to recompile and execute. And, since my front-end is a chrome:// app, it caches nicely after loading once.
It really was more fun than I thought it would be. All I can say is, give it a try.