Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Mozilla Books Media The Internet GUI Programming Software Book Reviews IT Technology

Rapid Application Development with Mozilla 249

Posted by timothy from the zip-zap dept.
Matthew Morgan writes "Mozilla's strengths as an application platform often go unrecognized for lack of good documentation. Nigel McFarlane sets out to change that in Rapid Application Development with Mozilla. McFarlane describes his book as "a conceptual overview, reference, and tutorial" for building applications on the Mozilla platform. But does he have room for all three in one book?" Read on for Morgan's answer to that question.
Rapid Application Development with Mozilla
author Nigel McFarlane
pages 770
publisher Prentice Hall PTR
rating 7
reviewer Matthew Morgan
ISBN 0131423436
summary A good overview and tutorial for building applications atop Mozilla, though not a comprehensive reference.

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 End

The 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 Bad

So, 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.

Conclusion

RADM 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
This discussion has been archived. No new comments can be posted.

Rapid Application Development with Mozilla More

Rapid Application Development with Mozilla

Comments Filter:

  • Rapid Mozilla Development (Score:5, Funny)

    by Hot Summer Nights ( 771962 ) on Tuesday April 20, 2004 @02:08PM (#8919493)
    ln /usr/bin/konqueror /usr/bin/mozilla

  • Bugs (Score:3, Insightful)

    by Fiz Ocelot ( 642698 ) <baelzharon.gmail@com> on Tuesday April 20, 2004 @02:09PM (#8919503)
    I'll take less bugs over rapid development any day.

    • Re:Bugs (Score:3, Informative)

      by Anonymous Coward
      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.

  • Download link (Score:4, Informative)

    by Anonymous Coward on Tuesday April 20, 2004 @02:11PM (#8919520)
    Here [informit.com]

  • Support of large corporations (Score:5, Interesting)

    by sibdib ( 772980 ) on Tuesday April 20, 2004 @02:12PM (#8919530)
    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.

  • It's time to embrace XUL (Score:5, Insightful)

    by darthcamaro ( 735685 ) * on Tuesday April 20, 2004 @02:12PM (#8919532)
    I think its time for the dev community to embrace XUL as a cross-platform development tool. Too much is made of Qt and GTK - both are great, don't get me wrong..but XUL just doesn't get it's due respect.
    • Sounds great.

      Now for the question that determines whether or not i choose to believe you: why XUL over others?

      Please explain.

      • Re:It's time to embrace XUL (Score:4, Informative)

        by rjshields ( 719665 ) on Tuesday April 20, 2004 @02:47PM (#8920006)
        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.

    • Re:It's time to embrace XUL (Score:4, Informative)

      by Deraj DeZine ( 726641 ) on Tuesday April 20, 2004 @02:23PM (#8919690)
      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).

      • Re:It's time to embrace XUL (Score:4, Informative)

        by jrumney ( 197329 ) on Tuesday April 20, 2004 @02:32PM (#8919797)
        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

        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.

      • The Glade XML format is kind of strange (it looks like XML described in XML; a pointless scheme)

        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

    • Re:It's time to embrace XUL (Score:5, Insightful)

      by OmniVector ( 569062 ) <see my homepage> on Tuesday April 20, 2004 @02:27PM (#8919749) Homepage
      I don't deny that XUL is a good cross platform development tool, but Qt, GTK, and XUL are all very differnet things. Qt is a comprehensive C++ API, including networking, threading, images, GUI, and more. GTK is strickly a GUI toolkit, plus it's written in C which allows it to very easily be linked with almost anything. XUL is not a toolkit, but a platform-independent GUI description made with XML. This allows you to write XUL apps that look like native os x apps in os x, native windows apps, and well crappy skinned apps in linux. They are all different things really. So one can't mutally replace the others (i.e. XUL replacing Qt).

      It would be an interesting proof-of-concept though if someone wrote an XUL based desktop environment. So far XUL is really missing a killer-app (besides mozilla).
      • GTK is just a toolkit but it sits on top of glib, which is a C api to a bunch of that other stuff - the whole GTK family has basically all the stuff that Qt has, it's just seperated out more.

        As for XUL - as far as I'm aware, the only XUL-based application out there is Mozilla and XUL is tied very tightly to it - are there any XUL libraries for other, more native toolkits? There's at least a couple other XML based layout languages - wxWindows has one, Gtk has one, and I think Qt uses one now also. Whats th

        • Re:It's time to embrace XUL (Score:4, Insightful)

          by ciroknight ( 601098 ) on Tuesday April 20, 2004 @02:51PM (#8920069)
          XUL would shine as an application development environment in exactly the same way Visual Basic shined under Windows. You may argue that Visual Basic is a very weak language, but it was intended as such, and it was intended to be easy so that anyone could learn it quickly, and be developing apps quickly, therefore speeding up everything.

          What's more, XUL should let us do fairly easy localizations and the like. Not that this has been a problem in Linux since every major project has implemented some api to get around it, but for smaller projects that want to become bigger projects, it's nice to already have features like localization at your hands.

          I think it would be a fairly impressive, and quite snappy, user environment. With SVG coming to age and XML being embraced *even though I hate it*, it's good to see an actual Good Use (tm) of it.

          Furthermore, doesn't Mozilla require GTK libraries? I was under the impression that it used some code from GTK, but didn't actually render it's widgets and the like with it. I'm most likely wrong about this, but it's still interesting.
          • yes, mozilla does infact have a gtk port. if i'm correct, i believe this means it uses gtk's drawing functions to handle menus, buttons, etc, rather than pure xlib.

            likewise following this analogy, there should be a quartz and GDI port for native mac and windows.

    • Re:It's time to embrace XUL (Score:4, Interesting)

      by duffbeer703 ( 177751 ) * on Tuesday April 20, 2004 @02:32PM (#8919790)
      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.
    • If everyone embraces XUL and suddeny everything ends up becoming as dog-slow as Mozilla, I'll scream.

    • My problem with mozilla is not XUL, which I think is great. It's that javascript is the only language with built-in support. Sure you can add others, but unless they are there by default that is too much of an administrational burden and you can't rely on it.

      Mozilla needs to do one of two things (or both):
      a) include a java VM that can run apache BSF
      b) work with the parrot people and build it into Mozilla

      You can rest assured that Microsoft is working on multiple language support through a marriage of IE to

  • Web-installer.... (Score:5, Insightful)

    by kevlar ( 13509 ) on Tuesday April 20, 2004 @02:14PM (#8919562)
    The single feature that I wish I could get with my applications is the web-installer that Mozilla has for its install. It allows you to stop and resume a download and it would allow people with crappy dialups to download large files without having to restart after every disconnect.

    If I could build an installer with mozilla that would let me do this with _any_ application, that would be golden!!

    • Re:Web-installer.... (Score:5, Insightful)

      by Syberghost ( 10557 ) <syberghost@@@syberghost...com> on Tuesday April 20, 2004 @02:19PM (#8919638)
      It allows you to stop and resume a download and it would allow people with crappy dialups to download large files without having to restart after every disconnect.

      You realize FTP has had that capability since like 1985, right? And that Postel didn't invent it, either?

      • Re:Web-installer.... (Score:2, Insightful)

        by kevlar ( 13509 )
        You do realize you completely missed the point of my posting, right? I am fully aware of the capabilities of FTP. The problem is that when you have end-users who do not use, nor never will use an FTP client, FTP is useless. What I need is a web installer that'll download large files via whatever "resume" capable protocol and install my application. It all needs to be as simple as clicking on the executable. FTP Clients do _NOT_ offer this.

        But thanks for the condescending insight anyways...
        • You need to beat your users harder. Make them learn ftp. Tell them that if you wrote a click and drag application installer you'd be depriving them of the golden opportunity to learn.

          How did the world put the lemmings in control of the programmer?
          • The problem is the user is hands-down too stupid to learn anything new. They also are completely unwilling, and having to trouble shoot their FTP woes is not a direction I wish to move in since I'm trying to actually _SAVE_ time.
        • The problem is that when you have end-users who do not use, nor never will use an FTP client, FTP is useless. What I need is a web installer that'll download large files via whatever "resume" capable protocol and install my application. It all needs to be as simple as clicking on the executable. FTP Clients do _NOT_ offer this.

          Sigh. I'll try again.

          TAKE THE CODE FROM FTP AND USE IT IN YOUR INSTALLER. YOU CAN DO THIS BECAUSE IT'S FREE SOFTWARE.

          BTW, every web browser has FTP built in. EVERY SINGLE ONE.
    • Well... if you're willing to put in a few day's worth, you too can build a simple installer.

      Step 1: Find a simple ftp client engine. http://www.marshallsoft.com/fce4c.htm is one I googled for C - http://www.freesoft.org/CIE/RFC/959/index.htm if you want to write your own.

      Step 2: Write a simple GUI. Visual C++ can do this, or NetBeans for Java. However, if you're using Java then you have Java Web Start and why are you complaining, anyway?

      Step 3: Set your program up on an FTP somewhere.

      You're golden!

      But
  • 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.

  • Forbidden!! (Score:2, Insightful)

    by Anonymous Coward
    RADM is published in Bruce Perens' Open Source Series at Prentice Hall under the Open Publication License [opencontent.org].

    Doesn't look like a very open license to me.

  • The 5 Linux platforms (Score:5, Interesting)

    by aaron240 ( 618080 ) on Tuesday April 20, 2004 @02:19PM (#8919629) Homepage

    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?

    • Re:The 5 Linux platforms (Score:4, Interesting)

      by OmniVector ( 569062 ) <see my homepage> on Tuesday April 20, 2004 @02:35PM (#8919843) Homepage
      Eclipse? a platform? i think more specifically you mean:
      1. GTK
      2. Qt
      3. OOo's in-house toolkit
      4. XUL
      5. SWT

      as i said in another post in this thread, these are ALL different things. Each accomplishes different goals. These all share one thing in common: GUI. However each one encompasses other things. SWT for example is limited to java. Java cannot be distributed in just about any distro, so this rules it out as a viable platform. GTK is highly portable, but it is however horrible when it comes to any platform but linux. It runs in windows, without a windows theme to match. it runs in os x, but only via x11. Gtk's in a pretty sad state considering how "portable" it's supposed to be. Qt's one of the better-off toolkits, but it suffers from gtk's problems too. It's only good on linux. half-assed os x port (at least it's not x11 dependent) and the windows port is totally unmaintained (yay 2.0!). Openoffice is unskinnable, ugly, and requires X11 in os x. That rules it out. That really just leaves us with XUL. To be honest, XUL's not half bad. I've seen mozilla. it looks fantastic on all 3 platforms. can you say the same for any of these other toolkits besides SWT (which is java only and has licensing issues)? nope. XUL is WAY under appreciated i think.

      • Re:The 5 Linux platforms (Score:2, Informative)

        by Anonymous Coward
        He was talking about platforms, not toolkits. Platforms provide more than just GUI libraries -- they're application frameworks and component services.

      • Re:The 5 Linux platforms (Score:4, Interesting)

        by dominator ( 61418 ) on Tuesday April 20, 2004 @03:17PM (#8920418) Homepage
        "GTK is highly portable, but it is however horrible when it comes to any platform but linux. It runs in windows, without a windows theme to match. it runs in os x, but only via x11."

        BS. I guess that I didn't write the Gtk-wimp [sourceforge.net] theme engine, then. And I guess I'm not running Gimp, Gaim, Xchat, Dia, Inscape, and Workrave on Win32 right now... The gtk-wimp screenshots are out of date, btw, but are good enough to get the general idea across.

        GTK 1.2 has also been ported to Apple's Carbon framework. I have plans to do something similar for GTK 2.x.

        "Qt's one of the better-off toolkits, but it suffers from gtk's problems too. It's only good on linux. half-assed os x port (at least it's not x11 dependent) and the windows port is totally unmaintained (yay 2.0!)."

        Huh? Trolltech gets a lot of money from licensing QT 3.3 on Win32. I've licensed it. It's maintained, and works great. The OSX port isn't as half-assed as you'd like to think. It's not FOSS on Win32, like it is on OSX and *NIX, but that's Trolltech's decision, not mine.

        You're right, XUL may be horribly under-appreciated. But realize that's largely Mozilla's own doing. They've been promising a standalone GRE for about 5 years now, and have yet to follow through. Much of the Mozilla platform is meant for eventual public consumption, but it's not ready for that today. When I can 'gcc -o myapp -lMozillaGRE -lMozillaJScript', come tell me.
        • ah, my apologies then. i was unaware of this. perhaps gaim should ship with your theme then, because it doesn't. yes, there is a gtk1 port for native os x apps. however you'll notice it's about as ugly as can be, and does not resemble an os x app at all. my concept of a "native port" is a fully native-looking app, down to the buttons, menus, and everything.

          i believe the reason i said qt is at 2.0 for windows was that FOSS software can only use the 2.0 library, which is why it's impractical to use for cr
          • *) Gaim does ship with my theme. As does dropline GTK. As does the Gimp's GTK.

            *) The GTK 1.2 port for OSX does suck visually, but you mentioned "portability", so I thought I'd throw that in just for kicks. I wouldn't suggest using it in a production setting. They are, however, making some progress using the OSX Appearances Manager API:

            http://gtk-osx.sourceforge.net/pix/gtktestthing . aq ua.buttons.jpg

            *) The QT3 OSX theme also uses the Appearances Manager APIs. It's not perfect, but I don't think it's as
      • Qt/Windows is at version 3.01. Many successful Windows-based commercial apps have been written with it, by many different customers ranging from Adobe to Intel to NASA. It looks great on Windows XP, by the way. You are talking out of your ass here.

      • Eclipse? a platform?

        Yes. Try asking any of the dozens of embedded systems tool makers how they created their design environments based on Eclipse, which you apparently consider a non-platform. It's just as much of a platform as Mozilla/XUL.
      • SWT with GCJ builds sweet fast native code applications that compile and run everywhere I want to be, thank you.
    • Nat Friedman recently identified Linux as 5 platforms:
      1) Gnome
      2) KDE
      3) OpenOffice.org
      4) Mozilla
      5) Eclipse

      He forgot Motif, the insensitive clod! :)

  • Sho me the MONEY! (Score:4, Interesting)

    by mcrbids ( 148650 ) on Tuesday April 20, 2004 @02:20PM (#8919646) Journal
    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?

    • Re:Sho me the MONEY! (Score:4, Informative)

      by leoxx ( 992 ) on Tuesday April 20, 2004 @02:25PM (#8919719) Homepage Journal
      How about the Activestate IDE, Komodo [activestate.com]?
    • There probably aren't any apps that you would consider using. There are going to be plenty of apps that management gives you no choice but to use.

      Java webapps are the universe's way of sending people back to the 286 era of speed and functionality while allowing them to keep 32-bit color and sound.

    • Re:Sho me the MONEY! (Score:5, Informative)

      by Bill Dimm ( 463823 ) on Tuesday April 20, 2004 @02:49PM (#8920029) Homepage
      OK, you won't use it, but I did recently write a Mozilla application for MagPortal.com [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 [phptr.com] 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).
      • No, I don't have anything of value to contribue to this thread. -shrug-

      • You've got my interest. Care to provide an email address or Phone # I can contact you at? You can get an email address from my website. (See sig)

        -Ben

    • Re:Sho me the MONEY! (Score:4, Informative)

      by X-Nc ( 34250 ) <nilrinNO@SPAMgmail.com> on Tuesday April 20, 2004 @03:21PM (#8920498) Homepage Journal
      If you check out OEone's [oeone.com] HomeBase [oeone.com] 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.
    • Good question.

      I'm looking for the same thing for XWT - who's using it for something that I'd consider using myself?

      XWT tries to address a moderately similar problem - putting a GUI framework to talk to Web services running on remote systems. Rather than being constrained to using a Web browser interface, your XWT apps can look like "normal" applications while still running a thin client with everything downloaded over the wire.

      Great idea, interesting approach, but I can't yet find a compelling app that

  • Quick Question (Score:5, Interesting)

    by KillerLoop ( 202131 ) on Tuesday April 20, 2004 @02:21PM (#8919657) Homepage
    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?

    • Re:Quick Question (Score:3, Interesting)

      by jrumney ( 197329 )
      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?

      Java? But even with C or C++, once you've got the UI out of the way, and using a standard library for network and filesystem access (I assume Mozilla provides this), there ar

    • Re:Quick Question (Score:3, Insightful)

      by DdJ ( 10790 )
      Personally I'd like to see the application logic live in web services (as in WSDL/SOAP), with WS-Security support for authentication.

      Then the presentation layer could be done in something like Mozilla/XUL on Linux, .Net Windows Forms apps on Windows and Pocket PC, J2ME on PalmOS and java phone devices, AppleScript Studio on MacOS X, and all sorts of other things (eg. our portal has a RAD framework for portlets, and it can slurp up web services with no trouble, and I'm sure there must be at least one BREW d
      • Sounds nice, but why so many different versions of the presentation layer? A Java Applet and a Midlet should take care of most of those platforms, and would be a lot less work to develop and maintain.
        • First of all, I don't know of a way to run Java applets or midlets on PocketPC devices. If you know of a way, let me know. Also, I don't know of a way to run them on PowerPC or ARM or Alpha Linux boxes, which is a concern for me, at least.

          Also, native apps often look and behave better than Java apps. I use MacOS X and PalmOS 5. Do I use Java apps? Yes. Do I use any MIDlets? Yes. Given the choice between a Java app and a Cocoa app, which will I use? The Cocoa app. Given a choice between a MIDlet a

          • Re:Quick Question (Score:3, Informative)

            by jrumney ( 197329 )
            There are a number of JVMs available for Pocket PC devices, either as MIDP, J2ME Personal Profile, or its predecessor Personal Java, the latter two being Java 1.1.8 compatible and capable of running applets. The exact versions available depend on the underlying processor, but Creme, Jeode and IBM's J9 are ones I've encountered. HP have a Java 2 [hp.com] implementation for Linux on Alpha, and older versions of 1.1.7 (which if you're targeting lowest common denominator applets is sufficient) have been available for y

            • Re:Quick Question (Score:3, Insightful)

              by DdJ ( 10790 )

              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?

              Actually, no. That's exactly what I do not want. I want an app that conforms to each platform's UI guidelines. The UI guidelines of the different platforms are incompatible with each other, though. An app that behaved exactly the same on e

      • Re:Quick Question (Score:3, Insightful)

        by bwalling ( 195998 )
        Mozilla/XUL on Linux, .Net Windows Forms apps on Windows and Pocket PC, J2ME on PalmOS and java phone devices, AppleScript Studio on MacOS X

        Uhh, Mozilla/XUL runs on Linux, Windows and MacOS X. Why would you develop three different times when you could do it once?

        • Uhh, Mozilla/XUL runs on Linux, Windows and MacOS X. Why would you develop three different times when you could do it once?

          Some people might do so because they prefer native apps to cross-platform apps (for example, under MacOS X it's easier to make the behavior of Services consistent that way -- as things stand, I don't run Mozilla on MacOS X because it's not as well-integrated with the OS as Safari is).

          But the point I was really trying to make is that by using web services, you could enable that strate

  • Sounds like a soon-to-be-added edition (Score:5, Informative)

    by elmegil ( 12001 ) on Tuesday April 20, 2004 @02:27PM (#8919735) Homepage Journal
    This sounds very much like it actually delivers what Creating Applications With Mozilla [amazon.com] promised. After reading CAwM first 3 chapters, having them completely confuse all the various issues in my mind, a wrote this review [amazon.com]. 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.

  • XUL? (Score:4, Funny)

    by Conspiracy_Of_Doves ( 236787 ) on Tuesday April 20, 2004 @02:27PM (#8919737)
    Ok, who is going to be first with the Ghostbuster jokes?

    • Re:XUL? (Score:4, Funny)

      by happyfrogcow ( 708359 ) on Tuesday April 20, 2004 @02:32PM (#8919794)
      [evil_voice_over]
      There are no Ghostbuster jokes, only XUL
      [/evil_voice_over]

    • Re:XUL? (Score:3, Informative)

      by rufus t firefly ( 35399 )
      Ok, who is going to be first with the Ghostbuster jokes?

      Check the XUL specification. It uses http://www.mozilla.org/keymaster/gatekeeper/there. is.only.xul which is a Ghostbusters reference.

  • Here's the unencrypted PDF and source code. (Score:5, Informative)

    by Bruce Perens ( 3872 ) <bruce@perens.com> on Tuesday April 20, 2004 @02:27PM (#8919741) Homepage Journal
    Here's the unencrypted PDF in a .zip file [informit.com].

    Here's the source RTF document in a zip file. [informit.com] 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

  • Mozilla + Trailblazer = drool (Score:5, Interesting)

    by System.out.println() ( 755533 ) on Tuesday April 20, 2004 @02:32PM (#8919799) Journal
    Maybe if someone could read this book and combine Mozilla [mozilla.org] with Trailblazer [uiuc.edu] we would have the best browser ever.

    And don't suggest me. I'm far too lazy. ;-)

  • I've recently read this... (Score:4, Interesting)

    by cliveholloway ( 132299 ) on Tuesday April 20, 2004 @02:54PM (#8920123) Homepage Journal
    ...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 ;-)

  • Cross Platform kits and Native Interferaces (Score:5, Interesting)

    by melatonin ( 443194 ) on Tuesday April 20, 2004 @03:49PM (#8920888)

    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

    Foo.app/Contents/
    -/MacOS/
    --Foo (executable)
    -/Windows/
    --Foo.exe
    -/Sparc/
    --F oo
    -/Resources/
    --MainWindow.nib (interface file for the main window; controls and stuff)
    --ToolWindow.nib (interface for tool window; no french version)
    -/French/
    --MainWindow.nib (french version of the main window)
    --Localized.strings (localized strings for the entire app, excluding those translated in MainWindow.nib)

    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.


  • Does it mean "Develop applications rapidly" or "Develop rapid applications"?

    If Mozilla itself is any example, Mozilla and XUL can only be used for rapid development of antirapid (i.e. sluggish) applications.
  • Found this in Firefox's config files. Check it out (and read the full URI):

    There is no data. There is only XUL [mozilla.org]

    Warning In the past, I've had versions of Explorer crash on me when looking at that page, so you may want to try it only in non-IE browsers (YMMV).
  • A friend of mine is involved in a project where they are using Microsoft .Net to add an entry in the default popup menu on a webpage. This of course only works on windows and in IE.

    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?

  • Doing real work with Mozilla (Score:3, Informative)

    by rycamor ( 194164 ) on Tuesday April 20, 2004 @10:40PM (#8924952)
    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.

    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 ... 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.

    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.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close