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
Oracle is going to write their applications so that they take advantage of the rich client opportunities that XUL provides. They are going to use Mozilla as a platform in much the same way that the Komodo IDE is based on Mozilla. XUL allows developers to do much more than they could with just HTML.
This is a great opportunity to show what Mozilla is truly capable of. In may ways Mozilla offers today what Microsoft is only planning to release with Longhorn. Not to mention the fact that Mozilla is Free Software and platform independent. It's made to order for developing and releasing rich client applications on a wide variety of platforms.
Finally. More documentation on RDF is always welcome. I hope this has some specific information on developing Mozilla extensions, because the available docco really sucks.
Nat Friedman recently identified Linux as 5 platforms:
1) Gnome
2) KDE
3) OpenOffice.org
4) Mozilla
5) Eclipse
Considering that each of these are at least marginally successful as platforms, a coherent platform doesn't seem to be in the cards for Linux. Many of us think that's perfectly fine.
My only concern is whether Mozilla is at least viable as a platform. Can developers assume their apps will run well for many users if they build in XUL?
I've heard about Mozilla's "RAD" capabilities, and I've heard all about "how flexible" it all is...
But - is there a single application that I'd consider using, written with Moz, other than Moz itself?
Anybody? One? Just one?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I'm always wondering where you put the actual logic in this kind of setup. You write your business logic as XPCOM components in ... what? C++? Java? Python? Javascript?
I was given to understand that Mozilla as application platform should be platform independent. But what about the actual code apart from GUI and the necessary wiring?
The problem is the XUL has been basically undocumented until now and very closely linked with Mozilla.
Mozilla rocks, but it took them until 2001 or so to produce a better browser than IE.
Conformity is the jailer of freedom and enemy of growth. -JFK
Maybe if someone could read this book and combine Mozilla with Trailblazer we would have the best browser ever.
;-)
And don't suggest me. I'm far too lazy.
I've got more mod points and GMail invi
"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"
This is a rather important point that gets short thrifted. How many times have we logged into "/." to listen to another usability complaint? And the UI people complaining that the programmers don't listen to them, and the programmers complaining that the UI people don't understand what's involved? Well here's the solution staring people in the face. Just as the web people have learned the seperation of content from everything else. The GUI people have the look seperated from everything else, were they can go off and do their own thing, then come back and merge with the programmers. Sounds like a win, win for everyone, except maybe the armchair critic that secretly doesn't want Linux to succeed.
...and found it cluttered. It's like they took the tutorial pages and the appendix and decided to shuffle them together.
;-)
The listings are only for parts of an application at a time, making it hard to visualize the whole project.
It could really do with having stand alone examples for each chapter or, at the very least, have an associated web site with such content (the listings could, I guess, get a little out of hand).
It may just be me, but seeing snippets out of context is not how I learn things.
I think it would have been better if they started off by presenting the whole of the notetaker program, and then analysed each section to explain what it did, and leave the detailed descriptions of tags to appendices.
In its defence though, there's so much to learn that it would be hard to make a good tutorial in one book along with the reference material - whatever the approach.
I'm still waiting for a perfect book on Mozilla Application Development. Kudos to anyone who manages to write one though - there's so much to cover.
cLive
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
I think everyone agrees that most x-platform tookits have one glaring weakness - all the platforms share the same user interface. Mozilla supports skinning, which is nice, but it doesn't feel like a Windows application or a Mac application. It feels like an XUL application. NeXT had fantastic x-platform support with OpenStep; it's also how it (and Cocoa) acheive localization. That technique should be able to be used with other toolkits, even if they don't have 'native' support for that technique.
Let's take a look at localization first. Typically, you generate a .strings file for each language. That kinda sucks because if you just did that, all localized versions would share the exact same window and control (widget) dimensions. The following is what Cocoa (OpenStep) does. Each application 'binary' is actually a directory with this kind of layout
Hopefully that's self-explanatory. Basically each platform gets its own version of an executable, and each language gets its own version of the interface (falling back to the basic definition in Resources/ if no version for a specific language is found). Well the next step is obvious. If you want to create a windows specific .nib, you create a MainWindow-windows.nib, which will only be used over MainWindow.nib on the Windows platform. Native controls are used on each platform, regardless if there's a platform-specific nib or not.
It's a shame that Cocoa is no longer x-platform (although the support is still there, it's just that the runtime isn't available on other platforms). But this should be possible with other platforms too; you just need to encapsulate resource loading and load the appropriate resource for each platform and localization.
Moderators should have to take a reading comprehension test.
RAD is usually targetted at quick-and-dirty application with a GUI. Something where usability is the most important factor. I would never develop a banking system with a RAD tool given the number of transactions/secs, error recovering and other stuff which are required and much more important than a flashy GUI to it.
Achille Talon
Hop!
Too many companies sell "intranet applications" for things such as timesheets, knowledge management... that are IE only because they try to imitate Windows application look. When you have one of theese, your are "IE-locked".
Do you think it is any better?
At least, the Mozilla platform is free and available on other OS than Win32.
I would love to be able to present for him a solution that works for mozilla as well. Is it possible to add an entry, say "Print 5 Copies" to the default popup menu below "Save Page As", and have that run some javascript (or something else) using any of the mentioned RDF/XBL/XUL?
When you are sure of something, you probably are wrong (search for "Unskilled and Unaware of It").