Slashdot Mirror
Creating Applications with Mozilla
On the first and most obvious level, the book is just the typical, thorough treatment of the important APIs that we've come to expect from O'Reilly. There are chapters addressing all of the important layers of the Mozilla platform and plenty of examples that show you how to customize the platform. Some may want to change the icons and others may want to add more robust features. The range of possibilities is surprising and coders are creating one-to-one communications enhancements, add-on widgets, and even games. There are certainly some things missing, and some areas that could use more detail or more complicated examples, but the book is already 454 pages long.
On another level, this book is also one of the first finished documents that explains what the Mozilla group has really been up to for the past five years. Some have abandoned the project, and others have attacked it as fundamentally misguided. This book shows why it took so long by demonstrating all of the cool features added during the long march to a new, thoroughly extensible architecture.
Are the results enough to justify the time and the effort? Some note that the features may be a bit overhyped, because building your own browser with the Mozilla API is like making a pizza with $15 and a telephone. While there's a large part of the book devoted to the work you can do to change the look and feel of the buttons on your browser, the book and the project offer much more. The Mozilla project is one of the biggest threats to simple tools like Visual Basic to come down the pike in some time. The various layers offer many ways to provide good, customizable interfaces to databases, the web, and much more. I can see how many corporate development shops may want to start making Mozilla the platform for a license-free front-end, simply because it's a straightforward tool without extra costs or restrictions.
At the most abstract level, the book is a great way to get a taste of modern software development. Computer scientists sometimes fix problems by adding more and more layers of indirection. This may not solve anything, but at least there are hooks for a real solution to use some time in the future if some one ever does figure out how to make the box do it. The Mozilla browser is one of the most extreme examples of this philosophy to ever emerge. Emacs was something special, but this is even more insane. Everything can be changed around by rewriting some XML and Javascript and most people don't need to juggle the pointers in grubby C to do amazing things. I realize it's not as beautiful as Lisp to some, but it's got a clarity and level of abstraction that's stunning to behold. Lisp was just procedural, while XML is more like logic programming.
This relentless customizability embodies one of the deepest reasons for the success of open source. Technology is inherently complicated and the only way we can use it is if we can look under the hood. You can say all you want about CVS trees and bazaars filled with competing code, but opening up the interface is one of the most powerful themes of open source. It's not about teaching people to build their own VCR or PVR from scratch, getting the VCRs for free or even debugging the VCR's source code -- it's just about making them easy enough to program.
The book illustrates how Mozilla opens up the API to create a relatively easy language for people to use. The real open source is not the C in the tar ball, but the XML interface spelled out in the book. Many people feel that the most important thing that the first browser designers did was make it easy for people to see the HTML tags marking up the document in front of them. The new Mozilla takes this transparency to a new high.
If you look at the book at all of these levels, you can see that this is one of the most important documents to emerge from the open source community in some time. At first glance, it's just another set of APIs for us to wiggle. I realize it's not fair to credit the Mozilla team or the book authors with creating the browser or XML ex nihilio -- they just jumped on some of the most popular bitwagons propagating across the Net. But the result is a stunning completion of a very important and cohesive vision. The book doesn't crackle with bleeding-edge novelty, but shines with the certainty of a job well-done.
Peter Wayner is the author of Translucent Databases , Disappearing Cryptography , and a number of other books. You can purchase Creating Applications 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 is one way in which you just know that the Mozilla developers are at the top of their field(s) -- deciding to go with XML full-fledged (several years ago, too) was one of the greatest decisions they've made so far. The XUL interface, which is basically XML-based at its core, is about as flexible as one can get with the UI experience.
Furthermore, and of particular interest to someone like myself, the XML format offers a number of advantages for computational physics: clear markup of input data and results, standardized data formats, and easier exchange and archival stability of data.
I will definitely use a few dollars of grant money to purchase this book and keep it in the labs for all to read and enjoy.
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
mozdev has it for free
In true open source fashion, the book is also available in online form at http://books.mozdev.org/chapters/
I've been developing some apps using Mozilla at work. I've been really happy with it, frankly. The GUI development couldn't be easier, you can create relatively complex widgets with it easily, and, with the exception of any compiled XPCOM objects you may have, it's cross-platform. We picked up a copy of this book as well, and it's quite good. I don't know if it's the wave of the future or not yet, but I rather hope so, because it would make my life a lot easier (especially when I have to write Windows apps; I'm not a big fan of the complex IDE tools Microsoft provides).
http://www.bookpool.com has it for $24.50
follow the [games] link in the review. thats what this web things alll about
You can browse different categories of Mozilla projects at MozDev.
Anyone planning to go to this probably knows already, but Brian King is giving a talk on Mozilla in Trinity College Dublin tonight. More details at http://netsoc.tcd.ie/events/0203/mozilla.php
-- Proud descendant of semi-nomadic cattle-herders.
But have you dabbled with web design? If the answer is yes, then you can write Mozilla apps. It's due to this fact that it's so easy to write patches for Mozilla. XUL (which if you know html is easy), CSS and JavaScript are all you need to know.
You could well be a programmer with Mozilla, and never know what a pointer is.
Having said that, 99% of XUL is now solid anyway. If you develop apps, the syntax may change or more likely you'll get new features, but if you then want to upgrade to that version of Mozilla, you can simply run the old XUL through some XSL transforms. It's the same as with any API really, except it's easier to upgrade/alter XUL.
Well the subject of my comment pretty much gives away the comment.
ActiveState http://www.activestate.com (The Perl,Python,PHP,Tcl people) have a great IDE application written on the Mozilla engine called Komodo, it's up to version 2 now and certainly worth checking out.
Now if only ActiveState would just open source it, after all it's base is open.
i have to say that i have converted a bunch of cgi's that deliver HTML to cgis that deliver XUL and provide RDFs. the interface is awesome ... so many things you cannot do with IE alone (unless you cookup some ActiveX)
... i hope an activex control for IE is around that will allow IE to use XUL
it was rough in the begining since i had people that were not using mozilla and even now some people just use mozilla because they have to.
but the power of the lists, tabs, etc are awesome compared to having to write javascript/layers/etc crap that takes more effort than the cgi environment to code.
i love it
members are seeing something, your seeing an ad
It's named OEOne
Very Insightful
There are a couple of very interesting examples developed using this technology out already:
- OEOne, a complete desktop environment.
- Kimodo, a python and perl IDE.
I myself am working on a Bible program that will run, locally, under Mozilla. This is probably the future of desktop application development for most stuff."He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
As pointed out in a discussion a couple days ago, this RedWolves2 guy is embedding his associates ID into his amazon links, in order to make a profit. And he's not telling anybody about it. He's done this a dozen or more times, and seems to be using Slashdot primarily for posting these Amazon ads. Moderators don't seem to be catching onto why this is a bad thing, and are modding up his posts. A user named Schlach had a couple great posts about why this is sleazy behavior. One's here, and the followup is here. Both are worth reading. Incredibly, I've been modded down for pointing out this questionable behavior on the part of RedWolves2. Read Schalch's comments and judge for yourself.
I'm generally "Interesting," "Insightful," and even "Funny" here. What the hell happens to me at parties?
komodo from activestate is a stunning example.
War is necrophilia.
I've been developing a Mozilla-based application component since August 2001. It's an HTML-rendering MOO client, and recently I've been pouring some 90% of my free time into working on it.
75% of that 90% of my free time lately has been updating the application to newer standards which have come into place since August 2001. For example, the Navigator/Mail/Editor/Chatzilla options used to be on the 'Tasks' menu in Mozilla, and were moved to the 'Window' menu around 1.0rc1. Bang, suddenly my application stops working properly, and less importantly, stops being a friendly component which works like all the others. A patch from a friend moved just about everything over to the 1.0rc1 way of doing things, and all was fine. Not everything worked flawlessly, though. The 'MOO Client' menu option didn't have an associated key visible, and the 'Window' menu inside MOOzilla didn't have any visible keys. The menus inside the application had long since stopped graying-out/disabling properly depending on what you have selected in the window. Many hours of last weekend was spent fixing these problems by conforming to new command handler expectations, and so on. (Where 'new' means 'changed since 0.9.6'. ;))
XUL is a wonderful tool. However, it runs dog slow on OS X. You don't have to take my word for it, just look at the Pheonix project. Pheonix is available for Windows and Linux, but not for OS X. Why? Because Chimera exists for OS X, which is faster (I'm using it right now) and integrates with the OS better. But... it doesn't support XUL. That's why it's faster. So where is my Mozilla application left? Stuck in the massive Mozilla suite when it's run in OS X. Mozilla, at startup, uses over 120 megs of RAM on my TiBook. Thank God for good VMs.
When initially writting MOOzilla, the XUL documentation was shit. The only place to go for any idea of how things really worked was deep inside the Mozilla source. And sure enough, this worked. The official XUL documentation at that time had sections which trailed off in 'blah blah blah' often because someone got bored of writting. I specifically remember it once read 'This is very important because blah blah blah'. Arrrg! How frustrating!
Mozilla is a powerful application development environment. XUL is a wonderful tool. Books like this one are going to make the world a better place for Mozilla component developers. And more cross-platform software developed with Mozilla makes the world a better place for users. Now... if only we can somehow apply this book heavily to the head of people who don't want to download Mozilla to try out an application, because they don't want to use it as a web browser. *sigh*.
*sigh*
All that IE does for Quicken is allow Quicken to use it as an HTML renderer. This is much different than Mozilla which can create a standalone application. The Quicken developers had to use C++ of VB or whatever and embed the MSHTML control into it. Mozilla does not require anything in addition to the package itself to create a new application. So even though this isn't necessarily new, it's definitely a lot more than IE can do on it's own. Plus you can embed Mozilla into apps like Quicken as well. Topstyle does a great job of integrating IE and Mozilla side by side using this technology.
Dissolve... Resolve... Evolve...
I do not do any database access with it (I've been using it to create client-side apps, and all our database access is on the server side); that said, I know it can access SQL databases using PHP. There may be other methods as well.
> How close is this Mozilla thing to supporting that?
Probably as close as it gets, without replacing every computer in the world with exactly the same OS. Fire up Mozilla and browse http://www.xulplanet.com/tutorials/xultu/
Try http://bitflux.ch/editor.IIRC from one of the authors of the book.
For remote access, all the server has to do is send XML data to Mozilla. Also, Mozilla natively supports the SOAP API, so it can access any SOAP data source. Cool, huh?
;-).
It's a little different if you are talking about accessing client-side data sources. Mozilla/XUL is (kind of) a virtual machine (VM), meaning it doesn't intrude too much upon the client's OS. But, XUL/XPCOM has bindings for all kinds of programming languages, such as C, C++, Perl, Python, Ruby, and the list keeps getting longer (Good intro here). Thus, on the client-side you can use the database capability of any of these to talk to the Mozilla elements. I'm sure it wouldn't be too hard to whip up just a little communication between Mozilla and ODBC