You are on page 1of 40

RDF RDF

JavaScript JavaScript
U
R
L
C
o
n
t
r
a
c
t
I
D
N
S
P
R
Digital
Certificates
Mozilla
registry
Preferences Type
libraries
JSlib
XPIDL
definitions
Class
libraries
RDFlib
C
o
m
p
u
t
e
r

O
p
e
r
a
t
i
n
g

S
y
s
t
e
m
S
e
c
u
r
i
t
y
X
P
C
O
M
JVM
Plugins
Components
JNI OJI
P
o
r
t
a
b
i
l
i
t
y
XPConnect
AppDevMozilla-01 Page 0 Thursday, December 4, 2003 6:22 PM
1
C H A P T E R
RDF RDF
JavaScript JavaScript
U
R
L
Templates Overlays
Overlay
database
XBL
definitions
DOM
Events
Frames
Gestures Text Keycodes
Mouse Keyboard
Widgets
Desktop
themes
GUI
toolkits
Fonts
Default
CSS
W3C
standards
DTDs
Skins
XBL
Screen

1

Fundamental Concepts

AppDevMozilla-01 Page 1 Thursday, December 4, 2003 6:22 PM
2 Fundamental Concepts Chap. 1

Thi s chapter i s an over vi ew of Mozi l l a ar chi tectur e and concepts, and i t con-
tai ns onl y a l i ttl e code. I f you are new to Mozi l l a, thi s chapter provi des ori en-
tati on and expl ai ns what you get for your ti me and effort. I t expl ai ns what the
pl atfor m i s, how Mozi l l a ts i n wi th XML technol ogi es, and how i t suppor ts
rapi d appl i cati on devel opment. I f you al ready appreci ate some of the archi tec-
ture, ski p di rectl y to Chapter 2, XUL Layout.
The Hands On sessi on i n thi s chapter contai ns some tr i vi al pr ogr am-
mi ng exampl es. I t pokes around i nsi de an exi sti ng Mozi l l a-based appl i cati on,
wri tes a tradi ti onal hel l o, worl d program, and begi ns the NoteTaker project
that runs throughout thi s book.
The NPA (Not Perfectl y Accurate) di agram at the start of thi s chapter i s a
structural di agram of the Mozi l l a pl atform. Each rectangul ar box i s a compl ex
subsystem that represents a chunk of technol ogy. Each chunk i s about equal i n
si ze to one or more software standards. These rectangul ar boxes are embedded
i nsi de the program that makes up the Mozi l l a pl atform; they are not parti cu-
l arl y separate. The smal l stacked rectangl es represent l es that si t i n a com-
puters l e system. The pl atform reads and wri tes to these l es as necessary.
Wi thout knowi ng anythi ng much yet, i t can be seen fr om the NPA di a-
gram that there i s a fundamental spl i t i n the pl atform. On the ri ght (the

front

)
ar e the mor e user-or i ented, XML-l i ke technol ogi es l i ke events, CSS (Cascad-
i ng Styl e Sheet) styl es, and the DOM (Document Object Model ). URLs (Uni -
for m Resour ce Locater s), the basi s of the Wor l d Wi de Web, ar e a key access
poi nt to these technol ogi es. On the l eft (the

back

) ar e the mor e system-or i -
ented, object-l i ke technol ogi es, such as components. Contr act I Ds (a Mozi l l a
concept) ar e a key access poi nt to these technol ogi es. The two hal ves of the
pl atfor m ar e uni ted by a pr ogr ammi ng l anguage, JavaScr i pt, and a data for-
mat, RDF (the Resour ce Descr i pti on Fr amewor k). JavaScr i pt i s ver y wel l
sui ted to the technol ogi es i nsi de the Mozi l l a Pl atform.
I t i s easy to see these two par ts of the pl atfor m. Open a wi ndow on any
Mozi l l a-based product, for exampl e the Netscape 7.0 Web browser or emai l cl i -
ent, and everythi ng you see i n that wi ndow wi l l be made from XML. Wri ti ng a
smal l pi ece of JavaScri pt code that submi ts an HTML form to a Web server i s
a tri vi al exampl e of usi ng objects associ ated wi th the back of the pl atform.
The vi ew provi ded by the NPA di agram does not transl ate i nto a tri cky or
r adi cal pr ogr ammi ng system. Pr ogr ammi ng wi th the Mozi l l a Pl atfor m i s the
same as wi th any pr ogr ammi ng envi r onmentyou type l i nes of code i nto a
l e. Unl i ke the r estr i cti ve envi r onment of a Web page, you ar e fr ee to wor k
wi th a very broad range of servi ces.

1.1 U

NDERSTANDING

M

OZILLA

P

RODUCT

N

AMES

The word

Mozilla

was ori gi nal l y a project name. Proposed by Jami e Zawi nski ,
an empl oyee of Netscape Communi cati ons, i n the 1990s,

Mozilla

was al so the
name of the green repti l e mascot for that project. I t i s a contracti on of Mosai c

AppDevMozilla-01 Page 2 Thursday, December 4, 2003 6:22 PM
1.1 Understanding Mozilla Product Names 3

Ki l l er, coi ned i n the spi r i t of competi ti ve softwar e pr oj ects. The Mosai c
browser was the predecessor of the Netscape 1.0 browser.
Si nce then, the term

Mozilla

has because i ncreasi ngl y overused. At one
ti me i t stood for a project, a product, and a pl atform; and

mozilla.org

came to
stand for an organi zati on. Now, Mozi l l a i s a generi c term for a cl uster of tech-
nol ogi es, just as Java and .NET ar e. Other ter ms ar e al so used for pr oducts
and technol ogi es wi thi n that cl uster. Mozi l l as home on the Web, sti l l referred
to casual l y as mozi l l a.org, can be found at

www.mozilla.org

Mozi l l a r st gai ned publ i c vi si bi l i ty when the Netscape Communi cator
5.0 Web appl i cati on sui te was announced as an Open Sour ce pr oject i n 1998.
The open source tradi ti on al l ows for publ i c scruti ny, publ i c contri buti ons, and
fr ee use. As ti me passed, Mozi l l a became a catch-al l ter m for ever ythi ng
rel ated to that 5.0 project. After more ti me, Mozi l l a 1.0 was decl ared ready i n
June 2002. That 1.0 r el ease r enamed the 5.0 pr oject to

Mozilla 1.0

. The 5.0
status of that project can sti l l be seen i n the user-agent stri ng of the browser
(type

about:mozilla

i nto the Locati on bar to i nspect thi s).
Now, ver si ons 6.0, 6.5, 7.0, and onwar d r efer to the sti l l -pr opr i etar y
Netscape-br anded pr oducts, l i ke Netscape Navi gator. Ver si ons 1.0, 1.1, 1.2,
and onward refer to the Mozi l l a Pl atform versi on, as wel l as to the Web appl i -
cati ons bui l t by mozi l l a.or g, that or i gi nate fr om the Netscape Communi cator
Web appl i cati on sui te.
I n thi s book, the terms

Mozilla

and

Mozilla Platform

mean the same
thi ngthe pl atform. Any Mozi l l a-based appl i cati on (e.g., an emai l cl i ent) uses
and depends upon a copy of the Mozi l l a Pl atform. The pl atform i tsel f consi sts
of an executabl e pr ogr am, some l i br ar i es, and some suppor t l es. I f the pl at-
form executabl e i s run by i tsel f, wi thout starti ng any appl i cati on, then nothi ng
happens.
The separ ati on between the Mozi l l a Pl atfor m and mozi l l a.or g appl i ca-
ti ons has become mor e obvi ous wi th ti me. What was once consi der ed to be a
very l arge appl i cati on sui te i s now consi dered to be a l arge pl atform on whi ch
a set of smal l er appl i cati ons are bui l t.
Unti l at l east ver si on 1.4, these smal l er appl i cati ons sti l l car r y thei r
Netscape names

Navigator

,

Composer

, and

Messenger

. They are al so ti ghtl y
i ntegr ated wi th each other. On one hand, thi s i ntegr ati on pr esents a uni ed
face to the user, a face ri ch i n functi onal i ty. On the other hand, thi s i ntegrati on
i s i nefci ent to mai ntai n because changes to one par t can affect the other
par ts. For that r eason, the br owser and emai l appl i cati ons have been r e-
i nvented as separ ate noni ntegr ated pr oducts at about ver si on 1.5. These
r epl acement appl i cati ons have the names

Mozilla Browser

(pr oject name:
Fi rebi rd) and

Mozilla Mail

(project name: Thunderbi rd). The i ntegrated sui te
conti nues to be avai l abl e as wel l .
Thi s spl i t-up of the sui te i s not a fundamental change of any ki nd. Both
i ntegrated and de-i ntegrated browsers share the same pl atform. Tool ki ts used

AppDevMozilla-01 Page 3 Thursday, December 4, 2003 6:22 PM
4 Fundamental Concepts Chap. 1

by ol d and new browsers are al so very si mi l ar. The appl i cati on l ogi c for ol d and
new browsers does di ffer markedl y, however.
Because the new noni ntegrated appl i cati ons are sti l l i n ux, and because
they are narrow i n focus, thi s book uses the ol der, i ntegrated appl i cati ons as a
r efer ence poi nt and teachi ng tool . Those i ntegr ated appl i cati ons ar e wel l
tested, demonstr ate near l y al l of the pl atfor m technol ogy, ar e better docu-
mented, and are sti l l up-to-date. They are a useful trai ni ng ground for grasp-
i ng Mozi l l a technol ogy.
I n thi s book,

Classic Browser

means the establ i shed and i ntegr ated
mozi l l a.org browser that i s part of an appl i cati on sui te.

Classic Mozilla

means
the whol e appl i cati on sui te.

Navigator

means a Netscape-br anded br owser
such as 7.0 or 4.79. The Cl assi c Br owser may di spl ay i ts content usi ng the
Cl assi c theme (whi ch l ooks l i ke Netscape 4.x sui te of products) or the Modern
theme (whi ch l ooks l i ke the 5.0 sui te of products). The Cl assi c theme i s there-
fore one step ol der than the Cl assi c Browser.
A nal product of the Mozi l l a project i s

Gecko

, al so cal l ed the

Gecko Run-
time Engine

. Thi s i s a stri pped-down versi on of the pl atform that contai ns onl y
a cor e set of di spl ay technol ogy. I t has not yet emer ged as a cl ear l y separ ate
product, but wi th i ncreased use of thi s name, i t i s l i kel y that Gecko wi l l be rec-
ogni zed separatel y.
To summari se al l that nami ng detai l , thi s book i s about the Mozi l l a Pl at-
for m onl y. I t uses the Cl assi c Br owser and other par ts of Cl assi c Mozi l l a to
expl ai n how the pl atform works, but i t i s about bui l di ng appl i cati ons separate
fr om those appl i cati ons. The NoteTaker r unni ng exampl e adds a tool to the
Cl assi c Br owser because i t i s too smal l to be an appl i cati on of i ts own. I f you
downl oad anythi ng for thi s book, downl oad the 1.4 rel ease of Cl assi c Mozi l l a,
whi ch contai ns the versi on 1.4 Mozi l l a Pl atform.
The remai nder of thi s topi c l ooks at some of the other names associ ated
wi th Mozi l l a technol ogy.

1.1.1 Platform Versions

Fundamental to Mozi l l a i s the Cl assi c Mozi l l a software rel ease. Many versi ons
of thi s combi nati on of pl atfor m and Web appl i cati on sui te exi st. Cl assi c
Mozi l l a contai ns a l arge subset of al l features wi th whi ch the pl atform i s capa-
bl e of deal i ng. The r emai ni ng featur es ar e unavai l abl e. The mai n ver si ons of
Cl assi c Mozi l l a fol l ow:

Stable or major releases

. These are versi ons x.0 or x.0.y; they provi de
a guarantee that cri ti cal features (i nterfaces) wont change unti l the next
major rel ease. Exampl es: 1.0, 1.01.

Feature or minor releases

. These have versi ons a.b, where b i s greater
than 0. Featur e r el eases pr ovi de enhancements and bug xes to major
rel eases. Exampl e: 1.4.

AppDevMozilla-01 Page 4 Thursday, December 4, 2003 6:22 PM
1.1 Understanding Mozilla Product Names 5

Alpha, Beta, and Release Candidate releases

. Befor e ver si on 1.4 i s
ni shed, versi ons 1.4al pha and 1.4beta are versi ons of 1.3 that are more
than 1.3, but nei ther ni shed nor appr oved for r el ease as 1.4. The
Rel ease Candi date ver si ons ar e near-compl ete beta ver si ons that mi ght
become nal rel eases i f they pass l ast-mi nute testi ng.

Talkback releases

. Al ter nate ver si ons of any r el ease mi ght i ncl ude
Tal kback technol ogy, whi ch captur es the br owser state when i t cr ashes
and emai l s the r esul t back to mozi l l a.or g. Thi s i s used for mean-ti me-
between-fai l ures engi neeri ng metri cs and for debuggi ng purposes.

Nightly and debug releases

. Rel eases cr eated ni ghtl y ar e compi l ed
fr om the ver y l atest changes and ar e the r el eases l east l i kel y to wor k.
They are compi l ed wi th addi ti onal debuggi ng features turned on, whi ch
ver y techni cal user s can use as anal ysi s tool s. Both the pl atfor m and
appl i cati ons contai n debuggi ng features.

Custom versions

. Because the sour ce code i s fr eel y avai l abl e, anyone
wi th a sui tabl e computer can compi l e the pl atfor m. Numer ous compi l e
ti me opti ons change the set of features i ncl uded i n the nal bi nary l es.
By modi fyi ng the defaul t set of featur es, custom pl atfor ms r un a r i sk.
The r i sk i s that the maj or i ty of for war d pr ogr ess assumes that the
defaul t features are al ways avai l abl e. Speci al custom versi ons must l i ve
wi th the fact that they may not keep up wi th mai nstream changes to the
pl atform and may not run some Mozi l l a appl i cati ons.
Thi s book uses nal , mi nor, or major rel eases of the standard pl atform.

1.1.2 Example Applications

Some of the better-known Web appl i cati ons bui l t on the Mozi l l a pl atform fol l ow:

Netscape 7.0

. Thi s i s the commerci al edi ti on of Mozi l l a and i ncl udes fea-
tures to support AOL Ti me Warners busi ness goal s i n the Web and I nter-
net space. The mai n techni cal di ffer ences ar e: suppor t for the AOL
concept of screen name; i ntegrati on wi th AOLs server-si de faci l i ti es; l ack
of popup wi ndow suppr essi on; custom cooki e handl i ng; and a gener al
cl eanup of the user i nter face. Netscape 7.0 i s based on Mozi l l a 1.01.
Netscape 6.x i s al so based on Mozi l l a; however, i t i s based on versi on 0.94
and i s hi ghl y buggy.

Compuserve 7.0

. AOL al so owns thi s ol der Web and I nter net cl i ent-
based ser vi ce, whi ch sti l l has a l ar ge user base. Ver si on 7.0 i s a Mozi l l a
1.01based tool .

AOL 8.0 for MacOS X

. Thi s i s AOLs agshi p Web and I nter net cl i ent,
wi th a ver y l ar ge user base and a hi ghl y custom i nter face. Wi th ver si on
8.0, the Maci ntosh ver si on of AOL has been moved fr om I nter net
Expl orer to Mozi l l a 1.01.

AppDevMozilla-01 Page 5 Thursday, December 4, 2003 6:22 PM
6 Fundamental Concepts Chap. 1

Mozilla Browser

. Thi s mozi l l a.or g Web br owser i s to be mor e compact
and streaml i ned than the Cl assi c Browser.
Two ver y extensi ve exampl es of non-Web appl i cati ons ar e gi ven by
OEone and Acti veState.
OEone (

www.oeone.com

) produces products i ntended to make personal
computers easi l y useabl e by novi ces. Thei r OEone HomeBase product i s a cus-
tom combi nati on of Li nux and an enhanced ver si on of the Mozi l l a pl atfor m
cal l ed Penzi l l a. I t provi des a compl ete system for i nteracti ng wi th a computer.
Fi gure 1.1 shows an arrangement of thi s Mozi l l a-based desktop.
Acti veState (

www.activestate.com

) produces i ntegrated devel opment
envi r onment (I DE) tool s for softwar e devel oper s. Thei r Komodo pr oduct i s
based on the Mozi l l a pl atform. Fi gure 1.2 i s a screenshot of that product.
I n addi ti on to Web and non-Web appl i cati ons, hi ghl y customi zed appl i ca-
ti ons are possi bl e. The standard Mozi l l a Pl atform provi des the same i nterface
on ever y desktop, whi ch i nvol ves some compr omi se. Ther e have been a num-
ber of attempts to create browser products that match the exact l ook and feel
of one speci c pl atfor m. These ar e deepl y customi zed offshoots of Mozi l l a.
Such offshoots use embeddi ng technol ogy not covered i n thi s book:
Fig. 1.1 OEone HomeBase desktop. Used by permi ssi on of OEone Corporati on
(www.oeone.com).

AppDevMozilla-01 Page 6 Thursday, December 4, 2003 6:22 PM
1.1 Understanding Mozilla Product Names 7

Chimera

. A Maci ntosh MacOS X browser based on the Cocoa i nterface,
wi th tradi ti onal Maci ntosh menus.

Galeon, Nautilus

. Br owsi ng tool s i ntegr ated cl osel y wi th the GNU/
Li nux GNOME desktop i nter face. Some of thi s i ntegr ati on i s addr essed
i n the standard pl atform wi th forthcomi ng support for GTK 2.0.

K-Meleon

. A Mi cr osoft Wi ndows br owser that tur ns Mozi l l a i nto an
Acti veX control . Tool bars are very si mi l ar to a si mpl e I nternet Expl orer.
The number of appl i cati ons based on the Mozi l l a pl atfor m i s steadi l y
growi ng, wi th announcements every month or so. The communi ty newscenter

www.mozillazine.org

i s a good pl ace to pi ck up announcements of new Mozi l l a
products.

1.1.3 Jargon Buster

Mozi l l a cul tur e and mozi l l a.or g documentati on contai ns some convol uted
sl ang. Coveri ng i t al l i s a hopel ess task. Refer to

www.mozilla.org/ docs/ jar-
gon.html

and to

http:/ / devsupport.mozdev.org/ QA/ thesaurus/

. A few of the
more vi si bl e terms fol l ow:

XP

. Cr oss pl atfor m, meani ng por tabl e, as i n XPCOM, XPFE, XPI nstal l ,
XPI DL.

FE

. Front end, the graphi cal di spl ay part of Mozi l l a.
Fig. 1.2 Acti veStates Komode 2.0 I DE. Used by permi ssi on and courtesy of
Acti veState (www.activestate.com).

AppDevMozilla-01 Page 7 Thursday, December 4, 2003 6:22 PM
8 Fundamental Concepts Chap. 1

BE

. Back end, the networki ng part of Mozi l l a.

I18n

. I nternati onal i zati on = I + 18 characters + n. Mul ti l ocal e support.

L10n

. Local i zati on = L + 10 char acter s + n. Customi zati ons for a gi ven
l ocal e.

The tree

. The Mozi l l a source code and compi l ati on system.

Bloat

. The tendency for any pr ogr am under goi ng enhancement to get
bi gger.

Landed

. Usual l y l anded functi onal i ty: addi ng ni shed changes to the
tree.

Dogfood

. Fr om eat your own dog food : testi ng wher e you tr i al your
own xes.

Porkjockeys

. Der i ved fr om yi ng pi gs. Those who seek to r edesi gn
Mozi l l a radi cal l y.

r=ada

. Changes revi ewed and accepted by Ada.

sr=ada

. Ch an ges s u per -r ev i ewed (ar ch i tectu r al l y r ev i ewed) an d
accepted by Ada.

Zarro Boogs

. Zero bugs; no current defect reports.
Fi nal l y, there i s an endl ess l i st of overl appi ng techni cal terms for the core
capabi l i ti es of Mozi l l a: Seamonkey, NGLayout, Necko, and mor e. Ver y few of
these ter ms map cl eanl y to a si ngl e, obvi ous appl i cati on technol ogy, so they
are general l y avoi ded i n thi s book.

1.2 T

HE

XML E

NVIRONMENT

XML (the Extensi bl e Markup Language) i s a hugel y successful standard from
the Worl d Wi de Web Consorti um (the W3C, at

www.w3.org

). Mozi l l a has exten-
si ve support for XML, so we bri ey revi ew what that standard i s good for.
The pr i mar y goal of XML i s to pr ovi de a notati on for descr i bi ng and
structuri ng

content

. Content i s just data or i nformati on of any ki nd. The cen-
tral XML standards provi de a tool ki t of concepts and syntax. That tool ki t can
be used to cr eate a set of descr i pti ve ter ms that appl y to one type of content,
l i ke vector graphi cs. Such a set of terms i s cal l ed an

application

of XML. The
most wel l -known XML appl i cati on i s XHTML, whi ch i s the XML ver si on of
pl ai n HTML.
XHTML descr i bes content that contai ns text, i mages, and r efer ences to
other XHTML documents, commonl y known as l i nks. Any parti cul ar exampl e
of thi s content i s cal l ed an

instance

or a

document

. Thus, XHTML denes

hypertext

documents, as opposed to any other ki nd of document. Ther e ar e
many other publ i cl y dened XML appl i cati ons, such as SVG (

vector graphics

content), MathML (

mathematical

content), and RDF (

resource description

con-

AppDevMozilla-01 Page 8 Thursday, December 4, 2003 6:22 PM
1.2 The XML Environment 9

tent). Mozi l l as own XUL speci es

graphical user interface

content. As an XML
exampl e, Li sti ng 1.1 i s a tri vi al SVG document.

Listing 1.1

A document that is an instance of SVG 1.0, an XML application.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC
"-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"
>
<svg width="500" height="400">
<rect x="35" y="32" width="300" height="85"/>
<text x="50" y="67">A Rectangle</text>

</svg>

The rst ve l i nes of thi s exampl e speci fy the document type; the rest i s
the document content. Usi ng an XML appl i cati on deni ti on, programmers cre-
ate softwar e that can pr ocess documents of that appl i cati on type. Such pr o-
cessi ng can be ei ther qui te si mpl e or compl ex. I n the case of Fi gur e 1.1, a
program mi ght take thi s document and di spl ay a rectangl e wi th the words A
Rectangl e i nsi de i t. A Web browser i s an exampl e of such a program. Process-
i ng of such documents can be ver y sophi sti cated. XML documents can be
tr ansfor med, tr ansmi tted, cr eated, chopped up, and combi ned, as wel l as
merel y di spl ayed.
The great success of XML rests on the fol l owi ng few si mpl e pri nci pl es.

1.2.1 Common Underlying Format

Al l XML documents, regardl ess of appl i cati on, have the same underl yi ng for-
mat. Thi s common for mat makes anal ysi s of al l such documents si mi l ar. I t
saves a gr eat deal of ener gy that woul d other wi se be wasted ar gui ng about
syntax. Such arguments typi cal l y have l i ttl e beari ng on the actual i nformati on
that those for mats contai n. That saved ener gy can be put to mor e i mpor tant
tasks, and softwar e no l onger needs speci al adaptor s to r ead the speci al for-
mats of other systems.
A fur ther consequence of thi s common for mat i s that i t pr omotes r euse
and enhancement of softwar e tool s. Common oper ati ons on the XML for mat
ar e now wel l known. Consequentl y, ndi ng or maki ng a tool that pr ocesses
XML i s easi er. Programmers can rel y on these features bei ng present i n most
modern tool s, i ncl udi ng Mozi l l a.

1.2.2 The Open-Closed Principle

The open-cl osed pr i nci pl e or i gi nates fr om the wor l d of object-or i ented (OO)
programmi ng. I t captures the i dea that a pi ece of software can be both ni shed
(cl osed) and yet sti l l avai l abl e for fur ther change (open). Thi s thi nki ng al so
appl i es to XML. The core XML standards are ni shed and certai n, as are vari -

AppDevMozilla-01 Page 9 Thursday, December 4, 2003 6:22 PM
10 Fundamental Concepts Chap. 1

ous appl i cati ons of XML; neverthel ess, anyone can create a new XML appl i ca-
ti on at any ti me. Thi s i s a hi ghl y exi bl e arrangement. Furthermore, the XML
standards al l ow parti al i nstances of XML appl i cati ons (cal l ed

document frag-
ments

) to be mi xed together i n one document. One document mi ght contai n
both XHTML and SVG content. That i s al so hi ghl y exi bl e.
Such exi bi l i ty i s a hi ghl y ui d si tuati on and provi des ferti l e ground for
i nnovati on. Document author s ar e fr ee to make any i nstance of a par ti cul ar
XML appl i cati on, whi ch i s just common sense. Softwar e devel oper s, however,
are free to make any XML appl i cati on deni ti on. New appl i cati on deni ti ons
can be the basi s for a whol e range of new document i nstances i n a new content
or appl i cati on area.
Mozi l l a benets fr om thi s exi bi l i ty. I t i mpl ements sever al i nnovati ve
XML appl i cati ons, pr i mar i l y XUL (XML User-i nter face Language) and XBL
(XML Bi ndi ng Language), upon whi ch many speci al -purpose XML documents
ar e based. I t al l ows pr ogr ammer s to pr ocess gener i c XML content and many
speci c XML appl i cati ons, l i ke RDF and XHTML.

1.2.3 Beyond English

Another benet of XML i s i ts abi l i ty to be expressed uni versal l y.
The Uni code standard i s a l i st of every character concept used i n human
wri ti ng. When a Uni code character reference and a font are combi ned, a vi sual
character (al so cal l ed a gl yph) can be di spl ayed. XML documents can refer to
any entry i n the Uni code standard, so XML i s a useful way to express i nforma-
ti on i n any l anguage on Earth.
Ear l y successes i n the moder n wor l d of computi ng occur r ed i n the
Engl i sh-speaki ng par t of the West, some at the Uni ver si ty of Cal i for ni a, Ber-
kel ey Campus, and some at AT&T. I t seemed at the ti me that ei ght bi ts (one
byte) was sufci ent to captur e al l the gl yphs i n common Engl i sh text. Thi s
resul ted i n the ASCI I character set, the C l anguages

char

type, and process-
i ng technol ogy i n the UNI X operati ng system al l bei ng xed to one byte. Thi s
l egacy has cr eated a hur dl e for the Uni code standar d, whi ch over al l r equi r es
two bytes per char acter. XML i s one way ar ound thi s hur dl e si nce i t star ts
agai n from the begi nni ng wi th a new format based on Uni code standards.
Mozi l l a i s an exampl e of a tool that handl es i nter nati onal i zati on i ssues
by r el yi ng on XML and Uni code technol ogy. I ts mai n suppor ted l anguage,
JavaScri pt, i s al so based on Uni code.

1.2.4 Hierarchical Thinking

The nal str ength of XML i s i n i ts i nter nal str uctur e. Documents cr eated to
XML standar ds consi st of fr agments of content nested i nsi de each other, i n a
hi erarchi cal way. Hi erarchi cal organi zati on i s a concept that humans nd easy
to grasp. As the ri ddl e goes, the man from St.Yves had seven wi ves, each wi fe

AppDevMozilla-01 Page 10 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 11

wi th seven sacks, each sack contai ni ng seven cats, each cat wi th seven ki ttens.
That i s hi erarchi cal thi nki ng.
Si mpl e concepts are especi al l y i mportant i n computi ng because worki ng
wi th computer s i s an abstr act task. Even outsi de computer s (e.g., thi s book),
hi er ar chi cal or gani zati on br i ngs or der to compl ex masses of i nfor mati on. For
computer pr ogr ammer s, the hi er ar chi cal natur e of XML i s an easy way to
express sol uti ons to probl ems and get somethi ng done.

1.3 P

LATFORM

C

ONCEPTS

Lets now turn to the nature of the Mozi l l a Pl atform i tsel f. A software pl atform
i s a pi ece of software that programmers use as a steppi ng stone. By standi ng
on the featur es of the pl atfor m (r el yi ng on the softwar e), the task of cr eati ng
hi gh-l evel functi onal i ty i s made easi er. Pr ogr ammer s need not waste ti me
maki ng basi c functi onal i ty usi ng l anguages l i ke C.
The four bi g steppi ng stones i n Mozi l l a ar e XUL, JavaScr i pt, RDF, and
XPCOM. XUL i s an XML di al ect used to construct user i nterfaces, JavaScri pt
i s a scri pti ng l anguage wi th syntax aki n to C, RDF i s an XML di al ect used to
store data, and XPCOM (Cross Pl atform Component Object Model ) i s an object
di scover y and management system. Those four i tems ar e di scussed exten-
si vel y throughout thi s book. Here we l ook at the overal l envi ronment i n whi ch
they l i ve.
From begi nni ng to end, the Mozi l l a Pl atforms mai n strength i s i n bui l d-
i ng vi sual , i nteracti ve appl i cati ons. I t i s not i ntended to be used to wri te dri v-
ers, servers, or batch processi ng systems. I t can easi l y provi de a front end for
such systems.

1.3.1 Architecture

Netscape Web products pri or to Mozi l l a were bui l t i n a hurry and were not as
structured or as open as mi ght be desi red. Thi s hi story heavi l y l i mi ted the use
and futur e of those pr oducts, and hel d Netscape back when i ts 4.x pr oducts
wer e competi ng wi th Mi cr osofts I nter net Expl or er and Outl ook Expr ess for
functi onal i ty.
Si nce then, Netscape, mozi l l a.org, and vol unteer programmers have had
the ti me, the tal ent, and the freedom to break a l ot of that earl y technol ogy down
i nto smal l er, more exi bl e pi eces. They have al so repl aced some poorl y concei ved
technol ogy wi th better sol uti ons. These pi eces together make up the moder n
Mozi l l a Pl atform and are better organi zed than i n the past. Thi s exi bi l i ty qual -
i es Mozi l l a as a pl atform rather than as a hi ghl y customi zabl e product.

1.3.1.1 A Layered Approach

The Mozi l l a Pl atfor m attempts to meet the
needs of sever al di ffer ent types of pr ogr ammer s, and the r esul t i s that i t has
been concei ved as a set of semi -i ndependent l ayers.

AppDevMozilla-01 Page 11 Thursday, December 4, 2003 6:22 PM
12 Fundamental Concepts Chap. 1

The l owest l ayer of the pl atform manages and i mpl ements a l arge set of
objects. These objects al l cooper ate i nsi de a si ngl e executabl e accor di ng to a
bui l t-i n medi ati on system. Mozi l l a needs a medi ati on system that i s hi ghl y
por tabl e, si nce i t r uns on many pl atfor ms. I n the end, a custom system was
desi gned for the pur pose. I t i s cal l ed XPCOM and i s at the cor e of the pl at-
form. Di rect access to XPCOM i s onl y possi bl e from the C and C++ l anguages.
The XPCOM system i s wri tten very careful l y so that i t compi l es and runs on
many di fferent operati ng systems. Fi l es hol di ng objects managed by XPCOM
can be seen i n the

components

di rectory of the standard Mozi l l a i nstal l ati on.
On top of XPCOM i s a very thi n l ayer cal l ed XPConnect. XPConnect pro-
vi des a JavaScri pt i nterface to XPCOM. The JavaScri pt l anguage i s a exi bl e
and l oosel y typed l anguage that can mani pul ate XPCOM objects ver y easi l y
and i n a portabl e way. Thi s l ayer provi des an appl i cati on programmer wi th an
accessi bl e and l ar ge object l i br ar y. That l i br ar y consi sts of al l the XPCOM
objects i n the pl atfor m. Debug r el eases of the pl atfor m i ncl ude a testi ng tool
cal l ed

xpcshell

, whi ch al l ows pr ogr ammer s to code di r ectl y at thi s l evel ,
al though that i s l ess commonl y done.
Some of the objects avai l abl e i n the pl atform are l arge and sophi sti cated
and can pr ocess XML content. These objects can pr esent a hi gh-l evel vi ew of
XML content to the pr ogr ammer. Such vi ews ar e based on the W3C DOM
standards, avai l abl e at

www.w3.org

. Thi s means that i nstead of parsi ng XML
text di r ectl y wi th handmade JavaScr i pt pr ogr ams, a pr ogr ammer can ask a
sophi sti cated object to swal l ow and di gest an XML document and i n r etur n
r ecei ve a hi gh-l evel set of i nter faces, l i ke the DOM 1 Document i nter face. I n
thi s way, JavaScri pt scri pts need onl y to consul t the XPCOM object broker for
a few powerful objects. From then on, scri pts can work di rectl y on the l arge set
of DOM objects produced when those few objects are gi ven an XML document.
Thi s DOM l ayer of functi onal i ty i s common i n most pr ogr ammi ng envi -
r onments wher e XML i s pr ocessed, i ncl udi ng i n XHTML Web pages when
Dynami c HTML scri pts are created. I n a Web page, there i s no hi nt that these
objects ori gi nate from XPCOM, but that i s sti l l the case. I t i s common for thi s
DOM l ayer to be sl i ghtl y enhanced so that i t i ncl udes other useful objects, l i ke
the window and navigator objects present i n Web-based JavaScri pt. Some-
ti mes securi ty constrai nts are i mposed as wel l . Al l thi s i s done i n Mozi l l a, and
that sl i ghtl y enhanced l ayer pr ovi des an envi r onment for a number of XML-
based content types, pl us HTML. Most i mpor tantl y, Mozi l l as own XUL has
such an envi ronment. Thi s l ayer i s the starti ng poi nt for the GUI s (graphi cal
user i nterfaces) that appl i cati on devel opers need to create. An exampl e of the
DOM Layer can be seen i n any HTML page that contai ns Dynami c HTML
scri pti ng.
Some XPCOM obj ects per for m thei r own sophi sti cated GUI di spl ay
tasks, notabl y l ayout and r ender i ng. The Gecko por ti on of the Mozi l l a Pl at-
for m i s a col l ecti on of objects that do thi s. These hi gh-l evel objects automate
the di spl ay of XML documents, gr aphi cs, and text. When an appl i cati on pr o-
gr ammer needs to di spl ay some content, a scr i pt can thr ow the content to
AppDevMozilla-01 Page 12 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 13
these l ayout and renderi ng objects and di spl ay automati cal l y happens wi thout
any further programmer effort. Thi s topmost, vi sual aspect of the pl atform can
be seen i n any Web browser wi ndow.
Fi nal l y, XML content and XPCOM objects can be ti ed together. Thi s can
be done wi th an XBL bi ndi ng, an XUL templ ate, or other l ess obvi ous
appr oaches. These Mozi l l a-speci c tacti cs extend the automati c pr ocessi ng
done by sophi sti cated XPCOM objects so that even hi gh-l evel tasks r equi r e
onl y smal l amounts of scr i pti ng. The tabbed navi gati on featur e of the
Mozi l l a browser i s an exampl e of a tag/object combi nati on created i n XBL.
I f that wer e al l of the Mozi l l a Pl atfor m, then the pl atfor m woul d be no
mor e than a JavaScr i pt i nter pr eter and a huge object l i br ar ynot much di f-
fer ent than Per l , Tcl , Vi sual Basi c, or even Java. The pl atfor m, however, al so
i ncl udes at the topmost l evel an application shell. Thi s shel l i s a mass of pl at-
form code that bi nds many of the XPCOM objects together i nto an executabl e
pr ogr am. Thi s pr ogr am i s abl e to automate and coor di nate many tasks, l i ke
connecti ons to server software, basi c document management, and i nstal l ati on
pr ocesses. The appl i cati on shel l , pl us many speci al -pur pose XPCOM objects,
r epr esents a r eady-made devel opment fr amewor k. I t i s mor e i mmedi atel y
useful than a passi ve set of l i br ar i es that cant do anythi ng unti l a pr ogr am-
mer chooses to use them. The appl i cati on shel l provi des the organi zati on and
i ntegrati on features that al l ow appl i cati ons to run on top of the pl atform. I t i s
al s o th e pl atfor ms appl i cati on ex ecu ti on en gi n e. Th e mozilla (or
mozilla.exe) executabl e i s a copy of the pl atfor m wr apped up i n an exten-
si ve appl i cati on shel l .
A substanti al porti on of a programmers work can be done merel y by cre-
ati ng XML documents. These are then suppl i ed to the appl i cati on shel l .
These l ayer s of the pl atfor m do not hi de each other fr om the pr ogr am-
mer. An appl i cati on programmers scri pt can perform operati ons at any l evel ,
i n any or der, subject to secur i ty constr ai nts. Common tasks that ar e i n keep-
i ng wi th the i nter acti ve, vi sual or i entati on of the pl atfor m can be achi eved
wi th ver y l i ttl e code that expl oi ts the hi ghest l ayer s of the pl atfor m. Hi ghl y
appl i cati on-speci c tasks r equi r e a mor e tr adi ti onal pr ogr ammi ng styl e i n
whi ch l ower-l evel objects are combi ned for an end resul t.
The remai nder of thi s di scussi on of archi tecture consi ders some of these
l ayers i n more detai l .
1.3.1.2 XPCOM Component Model A great strength of Mozi l l a i s i ts i nternal
structure.
At the l owest l evel , the pl atfor m i tsel f i s wr i tten i n the C and C++ pr o-
grammi ng l anguages. I n the case of a si mpl e C/C++ program, addi ng functi on-
al i ty means compi l i ng and l i nki ng i n mor e objects or functi ons. For l ar ge
projects, thi s i s an i mpracti cal and nave approach for many reasons.
One reason i s that the resul ti ng program wi l l grow huge and i nefci ent
to r un. I t i s al so i mpr acti cal because keepi ng tr ack of al l the i mpl emented
objects i s di fcul t. Fi nal l y, i f several di fferent projects are to use the software,
AppDevMozilla-01 Page 13 Thursday, December 4, 2003 6:22 PM
14 Fundamental Concepts Chap. 1
each one mi ght r equi r e onl y a por ti on of the pl atfor m. I n other wor ds, each
project must heavi l y modi fy the pl atform for i ts own ends or l i ve wi th a mi scel -
l any of objects that i t has no use for. Ther e needs to be a cl ever er appr oach,
and there i s.
An object br oker (al so cal l ed an object di r ector y, object name ser vi ce, or
object di scover y ser vi ce) i s a pi ece of code that nds objects and makes them
avai l abl e. I f al l objects bui l t provi de a standard or common i nterface that the
br oker can use, then al l member s of a l ar ge set of objects can be handl ed the
same way. That i mposes some uni formi ty on objects.
Mozi l l a objects ar e or gani zed i nto i ndi vi dual components. Components
are bui l t out of objects and i nterfaces. A component regi stry (a smal l database)
mai ntai ns a l i st of al l the avai l abl e components. A component name ser vi ce
that tur ns a component name i nto an object (i n object-or i ented ter ms i t i s a
factory) i s al so avai l abl e, as are a thousand components and a thousand i nter-
faces. Here i s an exampl e of a component name, wri tten i n Contract I D form.
The trai l i ng di gi t i s a versi on number:
@mozilla.org/browser/httpindex-service;1
The i nfr astr uctur e on whi ch these components ar e standar di zed i s
XPCOM. XPCOM i s a l i ttl e l i ke CORBA and a l ot l i ke COM, two other object
broki ng systems.
CORBA (Common Object Request Br oker Ar chi tectur e) i s a system for
gl ui ng together objects wri tten i n any of a number of programmi ng l anguages.
I n or der to do that i t descr i bes al l object i nter faces usi ng a l anguage-neutr al
syntax cal l ed I DL (I nterface Deni ti on Language). Mozi l l a i ncl udes a vari ant
of the CORBA I DL speci cati on technol ogy. The Mozi l l a ver si on i s cal l ed
XPI DL (Cr oss Pl atfor m I DL). I t i s a por tabl e (har dwar e- and oper ati ng-
system-i ndependent) l anguage that i s used to generate portabl e code and type
l i brari es.
COM (Common Object Management) i s a system for gl ui ng together di f-
ferent objects wri tten under Mi crosoft Wi ndows. Mozi l l a al so i ncl udes a vari -
ant of COM, cal l ed XPCOM (Cross Pl atform COM). XPI DL and XPCOM work
together i n Mozi l l a as a hybri d system that acts on COM-l i ke objects that are
descri bed by CORBA-l i ke speci cati ons. There i s no attempt to make XPCOM
a di str i buted system, l i ke DCOM (Di str i buted COM). I t i s r estr i cted to one
computer al one, and cur r entl y to one executabl e. Al though object speci ca-
ti ons ar e CORBA-l i ke, the XPCOM system dupl i cates the featur es of COM
qui te cl osel y.
Nearl y al l of Mozi l l a i s reduced to XPCOM components, and nearl y al l of
these components are scri ptabl e vi a JavaScri pt. Many components i mpl ement
Web pr otocol s or other networ ki ng standar ds. Thi s component model pl us
avai l abl e network components makes Mozi l l a l ook l i ke a mi ni ature versi on of
Mi crosofts .NET framework. I f pl atform components are wri tten i n C/C++, as
most are, then they must be wri tten accordi ng to stri ct portabi l i ty gui del i nes,
just as XPCOM i s.
AppDevMozilla-01 Page 14 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 15
1.3.1.3 Support for XML Software support for XML standards i s a matter of
degree. A program mi ght merel y be abl e to read an XML document, l i ke a l e
l ter, or i t may have i ts enti r e pur pose dedi cated to XML anal ysi s, l i ke an
XML database server. Mozi l l a l i es somewhere between these two extremes.
Mozi l l a does a better job of supporti ng XML standards than just readi ng
documents of that format. Mozi l l a has consi derabl e i nfrastructure for manage-
ment of retri eved XML documents; i n parti cul ar, i t has a si mpl e but sophi sti -
cated processi ng model for RDF. The best way to vi ew Mozi l l as XML support
i s as a system that can get XML from here and put i t there . To assi st that pro-
cess, a number of tr ansfor mati on techni ques can be appl i ed. Exampl e tech-
n i qu es i n cl u de mer gi n g an d l ter i n g docu men ts, man agi n g docu men t
fr agments, and per for mi ng ne-gr ai ned i nser t, update, and del ete oper ati ons
on the document structure and i ts content.
A fai r l y compl ete l i st of Mozi l l a-suppor ted XML appl i cati ons i s: XML,
XML Namespaces, XLi nk , XHTML (and HTML), MathML, SVG, XSLT
(Extensi bl e Styl esheet Language Tr ansfor mati ons), RDF, SOAP, WSDL (Web
Servi ces Descri pti on Language), and XML Schema.
Mozi l l a al so supports two XML appl i cati ons uni que to the pl atform: XUL
and XBL. XUL documents speci fy ar r angements of gr aphi cal wi dgets. XBL
documents r epr esent bi ndi ngs that bl end together a JavaScr i pt object and
XML content i nto a new pi ece of content. XUL i s a cruci al technol ogy for appl i -
cati on devel oper s. Look at any Cl assi c Mozi l l a wi ndow or di al og boxever y-
thi ng you see (except for any di spl ayed HTML) i s XUL content.
Mozi l l a suppor ts DTDs (document type deni ti ons) for many of these
standards. I t supports XML Schema deni ti ons for none of them. Of the sup-
por ted standar ds, the onl y ones that ar e i ntended for vi sual di spl ay ar e
XHTML/HTML, SVG, MathML, XUL, and XBL. The r est ar e used onl y for
data processi ng purposes.
1.3.1.4 Gecko Content Display Model To show the user XML content, some
ki nd of di spl ay system i s r equi r ed. That i s the job of the r ender i ng objects
i nsi de the pl atform that form part of the Gecko di spl ay subsystem.
The rul es that determi ne the l ayout of XML documents (and parti cul arl y
l ayout of HTML) have been shi fti ng i n the l ast few year s. Wher e those r ul es
used to appear i n standar ds such as HTML, they now ar e col l ected i nto the
styl i ng standards, such as CSS, DSSSL (Document Styl e Semanti cs and Spec-
i cati on Language), and XSL-FO (XSL For matti ng Objects). Thi s tr end i s
r eected i n the Mozi l l a Pl atfor m, wher e al l l ayout i s contr ol l ed by a moder n
CSS2 i mpl ementati on, whi ch i ncl udes many Mozi l l a-speci c enhancements.
The powerful CSS2 engi ne i nsi de Mozi l l a i s al so the heart of the Gecko l ayout
system. Mozi l l a al so uses CSS2 for pri nti ng.
XML documents are not i mmutabl e. I f del i vered from a remote l ocati on,
they can arri ve i ncremental l y. I f acted on by a programmer, they may grow or
shri nk. Modern di spl ay tool s need a sophi sti cated content model to support al l
ki nds of dynami c content changes duri ng di spl ay. Mozi l l a has a thi rd-generati on
AppDevMozilla-01 Page 15 Thursday, December 4, 2003 6:22 PM
16 Fundamental Concepts Chap. 1
content di spl ay system, al so par t of Gecko, whose ar chi tectur e i s contr asted
agai nst earl i er approaches i n thi s short l i st. Al though the l i st refers to XML, the
most obvi ous exampl e of a di spl ay system i s one that di spl ays HTML.
Mark I strategy. Read an XML documents tags one at a ti me and di s-
pl ay as you go. Pause the di spl ay pr ocess when not enough tags have
ar r i ved to gur e out the next step, maki ng the user wai t. Ver y ear l y
browsers di d thi s wi th HTML, l i ke Netscape 1.0.
Mark Ib strategy. Read al l of a documents XML tags i nto memory, put-
ti ng the user on hol d. Anal yze the document. Di spl ay the enti re document
at once. No popul ar browsers ever di d thi s, but XSLT performs batch pro-
cessi ng i n a si mi l ar way when used i n speci al i st pri nti ng software.
Mark II strategy. Read XML tags one at a ti me and di spl ay the page
usi ng pl acehol ders for content that i s anti ci pated but not yet read. When
that content arri ves, dynami cal l y repl ace the pl acehol ders wi th the real
content. Shufe everythi ng around to cl ean up changes each ti me pl ace-
hol ders are l l ed. I nternet Expl orer 4.0+ and Mozi l l a 1.0+ do thi s.
Mark III strategy. Read XML tags as for Mark I I , but possi bl y read con-
tr ol i nfor mati on as wel l . When the user or the ser ver mani pul ates the
contr ol i nfor mati on, fetch or r emove matchi ng content and update the
di spl ay wi th i t. Do thi s even after the document i s ful l y l oaded. Mozi l l a
1.0+, whi ch uses RDF as the control i nformati on, does thi s.
I t requi res a compl ex desi gn to i mpl ement a Mark I I I di spl ay model , and
Mozi l l as i nternal s are qui te sophi sti cated i n thi s area.
1.3.1.5 Support for Web Standards For tr a d i ti on a l Web p a ge d i s p l a y,
Mozi l l as Web standards support i s the best yet seen i n a Web cl i ent. The cl os-
est cur r ent competi tor i s the Oper a Web br owser. Al though thi s book i s not
about HTML, a br i ef r evi ew i s not enti r el y i r r el evant, si nce HTML can be
combi ned wi th XUL i n several ways.
I n the worl d of HTML, Mozi l l a has a legacy compatibility mode, a strictly
standards-compliant mode, and a nearly standards-compliant mode . The l eg-
acy compati bi l i ty mode does i ts best to support ol d HTML 4.01 and earl i er doc-
uments. The str i ct mode suppor ts the newer XHTML 1.0 onl y. The near l y
stri ct mode i s the same as the stri ct mode, except that i t provi des a mi grati on
path for ol der Web pages that l ook bad when di spl ayed str i ctl y accor di ng to
standar ds. Di r ecti ves at the star t of a Web page deter mi ne whi ch mode wi l l
pr ocess that document. I n al l modes, enhancements to the standar ds ar e
al l owed and some exi st.
Mozi l l a supports compl ementary Web standards such as HTTP 1.1; CSS2;
DOM 0, 1, and 2; and ECMAScri pt Edi ti on 3 (JavaScri pt). Mozi l l as Cascadi ng
Styl e Sheet (CSS2) suppor t has r ecei ved a gr eat deal of standar ds attenti on,
and a number of Mozi l l a extensi ons l ook forward to CSS3, or are merel y i nno-
AppDevMozilla-01 Page 16 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 17
vati ve i n thei r own r i ght. Onl y some par ts of DOM 3 ar e suppor ted. Mozi l l a
supports some of the accessi bi l i ty statements made by the W3C.
The worl d of HTML i s bei ng reduced to a number of smal l , separate stan-
dar ds and standar ds modul es that together make up the whol e of HTML.
Mozi l l a suppor ts XLi nk but not XFor ms. Si mi l ar l y, some of the DOM 3 mod-
ul es ar e suppor ted, whi l e other s ar ent. Si nce I nter net Expl or er 6.0 suppor ts
onl y the DOM standar ds to DOM 1, Mozi l l a i s wel l ahead i n the standar ds
adopti on game. Chapter 5, Scr i pti ng, expl or es standar ds compl i ance for the
DOM standards i n more detai l .
Mozi l l a support for MathML and SVG i s not compl ete. The MathML sup-
port i s cl ose to bei ng compl ete and i s extensi ve enough to be ful l y functi onal , but
the SVG support i s onl y parti al l y i mpl emented and i s not avai l abl e by defaul t.
1.3.1.6 Custom Tags and Objects Mozi l l a pr ovi des a speci cati on mecha-
ni sm for pai ri ng textual XML tags and compi l ed objects. Thi s speci cati on l an-
guage i s cal l ed XBL, an XML appl i cati on i nvented for Mozi l l a. XBL i s assi sted
by JavaScri pt, CSS, and other XML standards.
Wi th the hel p of XBL, a new XML tag that i s not mandated anywher e
el se can be dened. Thi s tag can be hooked up to pr ocessi ng l ogi c. The W3C
cal l s thi s l ogi c an action , but i t i s better known by the Mi crosoft term behavior .
I n Mozi l l a, such l ogi c i s created i n the form of a ful l object-ori ented object de-
ni ti on. The connecti on between the new tag and the processi ng l ogi c i s cal l ed a
binding . The object l ogi c can be wr i tten to take advantage of any of the ser-
vi ces avai l abl e to the pl atfor m, i ncl udi ng al l the XPCOM objects and other
custom tags that possess thei r own bi ndi ngs.
Because XBL al l ows new tags to be speci ed, Mozi l l a must be par ti cu-
l ar l y l i ber al when pr ocessi ng content. Any XML tag mi ght have meani ng
dened somewher e. XBL contr i butes to the near-zer o val i dati on aspect of
Mozi l l a, di scussed under the headi ng Consequences.
1.3.2 Innovations
The Mozi l l a Pl atform does not reduce to a set of objects and a set of XML stan-
dards ti cks. I t al so i ncl udes i nfrastructure that hol ds together processi ng and
appl i cati ons desi gned to expl oi t those objects and standards.
Some of thi s i nfrastructure contai ns new and i nnovati ve i deas. Most of i t
i s r equi r ed i f appl i cati on pr ogr ams ar e to be cr eated, i nstal l ed, and oper ated
correctl y.
1.3.2.1 Chrome and Toolkits The i nstal l ati on of a Mozi l l a appl i cati on can be
di vi ded i nto thr ee par ts. One par t i s a set of l es speci c to the user of the
appl i cati on, such as emai l addr esses and bookmar ks. One par t i s a set of
bi nar y l es contai ni ng the executabl e pr ogr ams of the pl atfor m, pl us a few
congur ati on l es. The nal par t i s a set of appl i cati on l es stor ed under a
di r ector y wi th the name chrome. Chr ome i s a centr al concept for Mozi l l a-
AppDevMozilla-01 Page 17 Thursday, December 4, 2003 6:22 PM
18 Fundamental Concepts Chap. 1
based appl i cati ons. An expl or ati on of the chr ome di r ector y i s i ncl uded i n the
Hands On sessi on i n thi s chapter.
I nsi de the chr ome di r ector y ther e ar e many subdi r ector i es, data l es,
documents, scri pts, i mages and other content. Together, the sum of the chrome
content, mer el y cal l ed the chr ome, r epr esents a set of r esour ces. Thi s set of
r esour ces i s r esponsi bl e for al l the user i nter face el ements pr esented by the
appl i cati ons i nstal l ed i n the pl atfor m. An appl i cati on may exi st enti r el y as a
set of l es i n the chrome.
Mozi l l a r efer s to l es i n the chr ome wi th the speci al URL scheme
chrome:. An exampl e of a chrome URL i s
chrome://notetaker/content/NoteTaker.xul
A chrome: URL i s usual l y a speci al case of a resource: URL. The
Mozi l l a-speci c resource: URL scheme poi nts to the top of the pl atfor m
i nstal l ati on area, so thi s URL i s usual l y equi val ent to the precedi ng URL:
resource://chrome/notetaker/content/NoteTaker.xul
Both resource: and chrome: URLs r epr es ent a s ubs et of al l the
r es ou r ces th at can be l ocated u s i n g a file: URL . Th e chrome: an d
resource: URL schemes, however, ar e pr ocessed speci al l y by the pl atfor m,
and a file: URL cannot al ways be used as a substi tute.
Gener al l y speaki ng, ever ythi ng i n the chr ome di r ector y i s por tabl e.
Al though there are al ways excepti ons, an appl i cati on i nstal l ed i n the chrome
of Mozi l l a on Mi crosoft Wi ndows shoul d have l es nearl y i denti cal to the same
appl i cati on i nstal l ed i n chr ome on UNI X or Maci ntosh. XUL documents ar e
usual l y stored i n the chrome.
Chrome i s more than a desktop theme, si nce i t can contai n both GUI el e-
ments and general appl i cati on l ogi c. I t i s more l i ke a sophi sti cated X11 wi ndow
manager such as the GNOME desktops Sawsh (used on Li nux/UNI X), or an
advanced theme engi ne on Mi cr osoft Wi ndows. Take the exampl e of Sawsh.
Sawsh can be congur ed usi ng scr i pts wr i tten i n a pr ogr ammi ng l anguage.
Thi s typi cal l y resul ts i n the addi ti on of buttons and decorati ons to a wi ndows
ti tl e bar. Sawsh cannot r each i nsi de the wi ndows i t decor ates; i t can onl y
pl ace decor ati ons on the outsi de of those wi ndows. Mozi l l as chr ome, on the
other hand, cannot reach outsi de the edges of a wi ndow, but i t can modi fy al l
the el ements i nsi de i t. I f Mi crosoft Word were i mpl emented usi ng Mozi l l a and
ran on UNI X, Sawsh coul d remove the styl i zed W from the top l eft corner of
the ti tl e bar, but i t coul dnt change any of Words tool bars. Mozi l l as chrome, on
the other hand, coul dnt r emove the styl i zed W, but i t coul d change the tool -
bars. Fi gure 1.3 shows a combi nati on of these GUI el ements together i n a si n-
gl e wi ndow. The wi ndow contai ns Sawsh wi ndow decorati ons, Mozi l l a chrome
status bar and tool bars, and a si mpl e HTML document.
Sawsh adds a fancy ti tl e bar wi th at l east four buttons. Fi l es i n the
chr ome add at l east two tool bar s, a menu bar, a status bar, and a col l apsed
si debar. The rest i s HTML.
AppDevMozilla-01 Page 18 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 19
The chrome al so contai ns a speci al l e named toolkit.jar. Thi s l e i s
an archi ve that contai ns a col l ecti on of commonl y used l es. The most i mpor-
tant thi ng i n thi s archi ve i s a set of deni ti ons that state whi ch XUL tags exi st
and what they do. Si nce Mozi l l a appl i cati ons ar e bui l t out of XUL, the pr es-
ence and content of thi s l e i s of vi tal i nter est to appl i cati on pr ogr ammer s,
and l i ttl e can be done wi thout i t. Thi s tool ki t i s suppl i ed wi th al l compl ete
r el eases of the pl atfor m. I t i s under goi ng mi nor change dur i ng the devel op-
ment of the new Mozi l l a Browser.
1.3.2.2 Themes, Skins, and Locales The Mozi l l a Pl atform supports a theme
system that al l ows the appearance of an appl i cati on to be vari ed and a l ocal -
i zati on system that al l ows the l anguage that an appl i cati on i s expressed i n to
be vari ed. Both systems work i nsi de the chrome di rectory.
I ndi vi dual themes i n the theme system are bui l t out of ski ns. A skin i s a
l e speci fyi ng the nonstr uctur al aspects of a Mozi l l a wi ndow, such as col or s,
fonts, and i mages. Ski n l es ar e a subset of the chr ome that i s automati cal l y
sel ected by the cur r ent br owser theme. Theme i n the l anguage of Mozi l l a
means Al l ski ns stor ed under the name of thi s theme. Some Mozi l l a advo-
cates ar e passi onate about desi gni ng thei r ski ns. I n the commer ci al wor l d,
ski ns ar e a way to package and br and appl i cati ons wi th cor por ate col or s and
marks or to make them t l ook-and-feel or desktop i ntegrati on standards.
Chrome URLs are modi ed by the current browser l anguage (the locale )
as wel l as by the current theme. Thi s means that supporti ng both an Engl i sh
Fig. 1.3 GNU/Li nux Mozi l l a wi th Sawsh Wi ndow Manager. Used by permi ssi on of
Arl o Rose.
AppDevMozilla-01 Page 19 Thursday, December 4, 2003 6:22 PM
20 Fundamental Concepts Chap. 1
and a Russi an Back button i s just a matter of havi ng chrome l es expressed i n
both l anguages.
1.3.2.3 Data Sources and Content Sinks An i nnovati ve system used exten-
si vel y i nsi de the pl atform i s the Producer and Consumer desi gn pattern. Thi s
patter n i s nor mal l y seen i nsi de object-or i ented l i br ar i es and l anguages. The
Mozi l l a Pl atfor m i ncl udes i nfr astr uctur e suppor t for a number of Pr oducer /
Consumer combi nati ons, wi th speci al attenti on to handl i ng of RDF-styl e data.
The Pr oducer /Consumer appr oach dedi cates pi eces of code to suppl yi ng
data (i .e., Producers, cal l ed data sources i n Mozi l l a) and other pi eces of code to
absorbi ng i t (i .e., Consumers, cal l ed content sinks i n Mozi l l a). Thi s separati on
of suppl y and demand al l ows i nfor mati on to be pumped ar ound i nsi de the
pl atform i n a exi bl e way.
RDF i s one of the more obscure W3C technol ogi es, and l i ttl e more can be
sai d i n thi s chapter wi thout starti ng a l ong di scussi on. Data sources and si nks
i nsi de the pl atform gi ve the programmer an opportuni ty to dri ve i nformati on
around an appl i cati on usi ng operati ons that are not so di fferent from database
operati ons. Thi s i n turn al l ows the pl atform to behave a l i ttl e l i ke a 4GL tool
used to bui l d database cl i ent software.
The most sophi sti cated use of data sources and si nks i nvol ves pool i ng up
RDF data for speci al processi ng. I nsi de the Mozi l l a Browser, RDF sources and
si nks can be connected by i nter medi ar y pr ocessi ng that acts l i ke a sophi sti -
cated l ter. Thi s l ter al l ows the content i n RDF data ows to be combi ned
and spl i t. Thi s i s done after the data ow i s sour ced but befor e i t i s sunk. I n
computer sci ence terms, thi s i s a si mpl e knowl edge processi ng system that i s
unusual for browser-l i ke software.
1.3.2.4 Competitive Features I n addi ti on to good desi gn, the Mozi l l a Pl atform
seeks to provi de a competi ti ve al ternati ve to Mi crosofts I nternet Expl orer. To
that end, i t needs features that gi ve i t an edge over that Mi crosoft browser.
Mozi l l as mai n strength i s compl i ance wi th W3C standards. The probl em
i s that standar ds compl i ance i s i nvi si bl e to end user swhen thi ngs go as
expected, there i s nothi ng to note. So Mozi l l a al so has ashy features that can
compete i n the end-user market. Some exampl es of these features fol l ow:
Auto-completion of forms. Mozi l l a can r emember what you typed i n
l ast ti me.
Type-ahead nd. You can reach a l i nk or any content on a page by typ-
i ng text.
Quick launch. Mozi l l a has caches and opti ons that make i t star t up
faster.
Image resizing. Mozi l l a pr oves si ze contr ol s for i mages di spl ayed by
themsel ves.
J unk email ltering. Mozi l l a has a l teri ng system to combat spam.
AppDevMozilla-01 Page 20 Thursday, December 4, 2003 6:22 PM
1.3 Platform Concepts 21
The Mozi l l a engi neeri ng staff al so mai ntai ns a set of performance objec-
ti ves for the product based on competi ti ve benchmarks wi th I nternet Expl orer
and Opera. There are regul ar i ni ti ati ves desi gned sol el y to tri m i nefci ent pro-
cessi ng from the pl atform, and from the browsers bui l t upon i t.
1.3.2.5 Remotely Sourced Applications The Mozi l l a Pl atfor m contai ns two
methods of access to Mozi l l a-based appl i cati ons l ocated on a remote Web server.
The si mpl er of the two methods i s the abi l i ty to downl oad an appl i cati on
and r un i t i mmedi atel y. Just as a r emote HTML document can be di spl ayed
l ocal l y, gi vi ng the user the opti on of l l i ng i n and submi tti ng a form, or cl i ck-
i ng a l i nk, so too can a remote XUL document be di spl ayed l ocal l y, gi vi ng the
user the opti on of wor ki ng wi th a for ms- and menu-dr i ven wi ndow that acts
l i ke a l ocal l y i nstal l ed program. Thi s aspect of the pl atform i s most si mi l ar to
that of Mi crosofts .NET i ni ti ati ves.
The other method i s to use the pl atforms XPI nstal l technol ogy. Thi s i s a
remote i nstal l ati on system that downl oads an archi ve from a remote Web si te
and i nstal l s i t i n the l ocal chr ome di r ector y per manentl y. A scr i pt gui des the
i nstal l ati on process, and the archi ve can contai n XUL-based appl i cati ons and
other l es of any ki nd.
I n both cases, the remote source appl i cati ons have some securi ty restri c-
ti ons, al though those restri cti ons can be l i fted i f the correct approach i s taken.
1.3.3 Consequences
Fi nal l y, some aspects of the Mozi l l a Pl atfor m emer ge fr om the sum of many
smal l changes.
1.3.3.1 GUI Integration Mozi l l a i s a di spl ay-or i ented tool , whi ch i s ver y di f-
ferent from other Open Source tool s l i ke Apache. Apache just si ts on a si mpl e
network connecti on and wai ts. Mozi l l a i s i nti matel y connected to the user and
the user s envi r onment. I t contai ns sever al str ategi es for wor ki ng wi th GUI s
and desktops.
At the l owest l evel , Mozi l l a rel i es on GUI wi dgets from a sui tabl e nati ve
tool ki t for the cur r ent pl atfor m. Thi s means GTK on Li nux, Wi n32 on Wi n-
dows, and the Maci ntosh tool ki t. A port of Mozi l l a that uses the Qt wi dget set
exi sts, but i t hasnt been mai ntai ned for a l ong ti me. Ther e i s no r aw X11
i mpl ementati on. The pl atform abstracts user i nput away from operati ng sys-
tem formats usi ng the DOM 2 Events standard.
At the desktop l evel , Mozi l l a r esponds nor mal l y to wi ndow oper ati ons
such as focus, i coni zati on, and exi t oper ati ons. I t i s wel l behaved on UNI X
under most X11 wi ndow managers. Recent versi ons of Mozi l l a support nati ve
desktop themes i n Wi ndows XP and i n GNOME 2.0. Mozi l l a supports content
sel ecti on and cut n paste to a degr ee, but thi s must someti mes be hand-
i mpl emented, and onl y happens automati cal l y i n the most obvi ous cases.
Mozi l l a al so supports mul ti format cl i pboard copyi ng. Thi s means that some of
AppDevMozilla-01 Page 21 Thursday, December 4, 2003 6:22 PM
22 Fundamental Concepts Chap. 1
the formatti ng i n a pi ece of sel ected content can be preserved when i t i s pasted
to another appl i cati on, such as Mi cr osoft Wor d. Mozi l l a suppor ts dr ag-and-
dr op mouse oper ati ons wi thi n the context of the appl i cati on, but agai n, some
hand-i mpl ementati on i s requi red. Si mi arl y, objects can be dragged from el se-
wher e on the desktop to a Mozi l l a wi ndow Wi thout hand-i mpl ementati on,
nothi ng wi l l happen, and no vi sual feedback wi l l appear. Most Mozi l l a-based
appl i cati ons i ncl ude l ogi c that supports some drag ndrop operati ons.
Fi nal l y, at the appl i cati on l evel , one of Mozi l l as gr eat str engths i s i ts
XUL wi dget descr i pti on l anguage, whi ch al l ows GUI el ements to be br ought
together i n a very si mpl e and efci ent way.
1.3.3.2 Portability Mozi l l a r uns on many di ffer ent oper ati ng systems and
desktops. At www.mozilla.org , the Mozi l l a Browser Pl atform i s test-compi l ed
ever y ni ght, and the r esul ts ar e bundl ed i nto downl oadabl e and i nstal l abl e
l es. At l east the fol l owi ng operati ng systems are supported:
UNIX: Li nux i 386/PowerPC, FreeBSD, HP-UX, Sol ari s i 386/SPARC, AI X,
I ri x
Mini computers: OpenVMS
Personal computers: Wi ndows 95/98/Me/NT/XP, MacOS 9.x/X, OS/2,
BeOS
There are al so experi mental ports to other pl atforms such as the Ami ga.
Mozi l l a has wel l -establ i shed suppor t for the GNU/Li nux oper ati ng system,
and GNU/Li nux i s wi del y por ted i tsel f. I t i s pr obabl y feasi bl e to por t the
Mozi l l a software to most GNU/Li nux hardware.
Mozi l l as portabi l i ty extends beyond mere pl atform avai l abi l i ty. Most fea-
tur es suppor ted ar e i ntended to be i denti cal acr oss pl atfor ms. I n par ti cul ar,
the l e types requi red to bui l d a Mozi l l a appl i cati on (XUL, CSS, DTD, proper-
ti es, JavaScr i pt, RDF, etc.) ar e al l enti r el y por tabl e for mats. I n theor y, a
Mozi l l a appl i cati on shoul d r un on al l oper ati ng systems that the pl atfor m
runs on, wi thout a porti ng cost. I n practi ce, mi nor di fferences mean that very
few appl i cati ons are 100% portabl e wi thout some testi ng and occasi onal xes.
1.3.3.3 Near Zero Validation I n the wor l d of communi cati ons pr ogr ammi ng,
a fundamental desi gn i s thi s: Tr ansmi t str i ctl y accor di ng to standar ds, but
when recei vi ng, accept anythi ng that i t i s possi bl e to comprehend. Thi s strat-
egy i s desi gned to i ncrease standards usage i n new systems wi thout i sol ati ng
ol der systems.
The Mozi l l a Pl atfor m i s a communi cati on devi ce, fr equentl y r ecei vi ng
Web pages, emai l , and other messages. I t fol l ows a communi cati on desi gn and
that desi gn i s vi si bl e to a pr ogr ammer. Except i n the case of str i ct mode for
HTML, the pl atform i nterprets recei ved XML and other documents very l i ber-
al l y, adapti ng to or i gnori ng many si mpl e mi stakes, omi ssi ons, and addi ti ons.
For an end user l i ke a Web sur fer, thi s l i ber al i nter pr etati on i s a good
i dea because i rri tati ng error messages are kept to a mi ni mum. For a program-
AppDevMozilla-01 Page 22 Thursday, December 4, 2003 6:22 PM
1.4 The RAD Environment 23
mer, thi s l i ber al i nter pr etati on i s a bi t of a ni ghtmar e. I t i s ver y easy to add
i nformati on to a Mozi l l a appl i cati on, onl y to have i t si l entl y i gnored or si l entl y
recorded. Thi s si l ence coul d resul t i f suppl i ed addi ti ons are not i mpl emented,
contai n typos, or ar e si mpl y i ncor r ect. As a pr ogr ammer, an extr a degr ee of
al ertness i s requi red when wri ti ng code for Mozi l l a.
Fortunatel y Mozi l l a does the most basi c of checks correctl y: XML content
must be wel l formed, and JavaScri pt and CSS code must at l east parse prop-
erl y. That i s a begi nni ng, but i t i s col d comfort for more advanced areas where
errors are more obscure.
1.3.3.4 Extensibility A strength of Mozi l l a i s that i t i s a pl atform, not just a
product. Al as, a weakness i s that i t i s onl y versi on 1 so far, and the pl atform i s
not as exi bl e or as compl ete as one mi ght hope.
Never thel ess, i t i s sufci entl y exi bl e that i t can be extended i n many
ways, fr om tr i vi al to fundamental . New objects can be added, even XPCOM
objects; new XML tags can be added; and new themes or l ocal es or appl i ca-
ti ons can be added. Ther e i s no need to r egi ster anythi ng wi th some centr al
body or to t i t i n wi th someone el ses l ogi c.
Because the pl atfor ms sour ce code i s avai l abl e, any enhancement at al l
i s possi bl e. Because Mozi l l as chr ome and XPCOM system ar e easy to use,
many exper i ments can be per for med wi th ease. Some exper i ments ar e done
wi thi n the Mozi l l a or gani zati on i tsel f, l i ke attempts to pr oduce a <canvas>
tag for XUL. Many other peopl e experi menti ng wi th Mozi l l a extensi ons can be
found at www.mozdev.org .
1.3.3.5 Security Mozi l l a suppor ts the secur i ty featur es of Netscape 4.x,
i ncl udi ng the powerful Same Ori gi n pol i cy. That pol i cy i nsi sts that i nsecure
oper ati ons, l i ke wr i ti ng a l e, be heavi l y r estr i cted. An i nsecur e oper ati on
r etr i eved fr om a gi ven i nter net l ocati on (a URL) can be attempted onl y on a
r esour ce that comes fr om the same l ocati on. Thi s r estr i cti on al l ows Java
appl ets to speak to thei r ser ver of or i gi n onl y. Si mi l ar l y, i t al l ows HTML or
XUL appl i cati ons to submi t data to the Web server at whi ch they ori gi nated.
The most notewor thy aspect of secur i ty i n the pl atfor m i s that appl i ca-
ti ons i nstal l ed i n the chr ome have no secur i ty r estr i cti ons at al l . Secur i ty
restri cti ons i mposed by the operati ng system sti l l appl y.
The pl atform has several securi ty model s to pi ck from; they are descri bed
i n Chapter 16, XPCOM Objects. The standar d pl atfor m i nstal l ati on i ncl udes
support for most di gi tal encrypti on standards and certi cate authori ty certi -
cates.
1.4 THE RAD ENVIRONMENT
Havi ng covered the pl atform bri ey, l ets l ook at the rapi d appl i cati on devel op-
ment (RAD) styl e of software devel opment and see what i t consi sts of.
AppDevMozilla-01 Page 23 Thursday, December 4, 2003 6:22 PM
24 Fundamental Concepts Chap. 1
RAD projects have some uni que characteri sti cs. The pri mary characteri s-
ti c i s just what i t says: rapi d appl i cati on devel opment. RAD projects have fast
del i very of ni shed work as a pri mary goal .
The Mozi l l a Pl atfor m i tsel f i s not a RAD pr oject. I t i s an Open Sour ce
project, where peer revi ew, i nnovati on, and archi tectural strategy are at l east
as i mpor tant as fast del i ver y. Fur ther mor e, the pl atfor m can be used i n
embedded softwar e pr ojects, a topi c not cover ed i n thi s book. Embedded soft-
war e has as i ts mai n constr ai nts footpr i nt si ze, r obustness, and l ow mai nte-
nance. Fast del i very i s not a cri ti cal pri ori ty for embedded software ei ther.
Because there are al ternati ves, speedy devel opment i s not just a matter
of adopti ng the pl atform. I t i s both a mi ndset and a process. Here are some of
the essenti al characteri sti cs of RAD projects.
1.4.1 Less Time, Same Effect
The qui ckest sol uti on you can nd that achi eves a desi red end i s probabl y the
best sol uti on. Thi s i s an essenti al char acter i sti c of RAD pr ojectsther e i s no
al l egi ance to any r i gi d r ul es. Whatever does the job fastest, wi ns. Even i f the
techni que you chose i snt that beauti ful , i snt that sophi sti cated, and maybe
i snt even that exi bl e, the fact that i t gets the job done i s essenti al . I f your
l abor can be pol i shed up afterward, that i s a pl us.
Dont agoni ze for years over the perfect desi gn. Make somethi ng work.
1.4.2 Visual Prototypes
Human users are the ul ti mate chal l enge i n software devel opment. They cant
be programmed rel i abl y, and thei r subjecti ve processes go strai ght through the
str uctur ed r ul es of softwar e. I t takes ti me and many exper i ments befor e a
user and a user i nterface are happy wi th each other. I n the acronym RAD, the
A for application guarantees the need for exi bl e user-i nterface experi ments.
RAD projects need the abi l i ty to create vi sual prototypes efci entl y.
RAD projects are not based on the concept bui l d i t and they wi l l come.
Fl exi bl e, changeabl e user demos are cri ti cal .
1.4.3 Vertical Solutions
RAD projects are used to bui l d products that have a narrow purpose, whether
i t be a museum catal og or a stock anal ysi s package. Those pr oducts ar e so-
cal l ed verti cal sol uti ons. There i s usual l y no need to make the product so exi -
bl e i t can be appl i ed to other uses. That can be a l ater goal i f the product works
as i s. So why i nsi st on a l ow-l evel , generi c tool , such as C++, Perl , or Tcl /Tk, as
the basi s for a product that i s a poi nt sol uti on? Use i nstead a speci al i zed tool
that ts the pr obl em spaceone that i s sui ted to the task wi l l be mor e ef-
ci ent. Mozi l l a i s speci cal l y ai med at several verti cal probl em spaces.
AppDevMozilla-01 Page 24 Thursday, December 4, 2003 6:22 PM
1.5 Effective RAD Projects with Mozilla 25
RAD projects can be bui l t on a narrow technol ogy base. Very generi c tool s
arent al ways better.
1.4.4 COTS Software Versus Home Grown
The not i nvented here argument of software devel opment, i n whi ch program-
mers object to usi ng other peopl es software, i s becomi ng harder and harder to
sustai n. As the total amount of code i n the wor l d i ncr eases, the chance that
your job has been done for you al so i ncr eases. Usi ng COTS (common-off-the-
shel f) softwar e i s a good techni que for savi ng ti me and effor t. I t gr eatl y
r educes the amount of pur e pr ogr ammi ng l abor and gets you a r esul t. Usi ng
COTS software makes perfect sense for RAD projects.
RAD pr ojects use other peopl es wor k r st and bui l d thi ngs by hand
second.
1.4.5 Destructured Testing
The constr ai nts of l ow-l evel pr ogr ammi ng l anguages l i ke C ar e wel l known.
Poi nter probl ems and strong typi ng make the use of a good compi l er essenti al .
The ar gument goes that usi ng the compi l ati on phase wi l l save ti me l ater
because i t i s a r i gor ous pr ocess. Less human testi ng wi l l be needed i f a com-
pi l er wi th a --pedantic opti on i s used.
I f programmers have a xed defect rate per hour, thi s argument i s proba-
bl y correct, even i f the l anguage i s a scri pti ng l anguage. Thi s argument, how-
ever, assumes that a nontr i vi al pr ogr am i s bei ng devel oped. I n the case of
RAD, usi ng a l ar ge exi sti ng tool (l i ke Mozi l l a) means addi ng smal l pr ogr am
fr agments r ather than bi g standal one chunks of code. A smal l pr ogr am fr ag-
ment i s easi er to cr eate cor r ectl y at the star t because i t contai ns few br anch
poi nts (few if statements). When pr ogr am fr agments r esi de i n a l ar ger tool ,
the tool al so acts as a permanent test harness. Hi ghl y formal testi ng i n such a
case can be overki l l .
RAD destructures testi ng because many smal l code fragments are more
l i kel y to be correct than one bi g program.
1.5 EFFECTIVE RAD PROJECTS WITH MOZILLA
Mozi l l a mi ght be an efci ent devel opment tool , but i t al so comes wi th a catch:
there i s too much sl ow i nformati on. Mozi l l as source code takes too much ti me
to under stand. Mozi l l as bug database i s a j ungl e to get l ost i n, and the
mozi l l a.org Web si te freel y mi xes new and ol d documentati on wi thout regard
for accuracy or age. Attempti ng to absorb al l thi s can undermi ne the reasons
for choosi ng Mozi l l a i n the r st pl ace. To keep the RAD benets of Mozi l l a
i ntact, so that you can get somethi ng done, here are some recommendati ons.
AppDevMozilla-01 Page 25 Thursday, December 4, 2003 6:22 PM
26 Fundamental Concepts Chap. 1
Most i mportantl y, grab the documents l i sted i n the Hands On secti on i n
the i ntroducti on of thi s book. Those documents, pl us a decent book, are enough
documentati on to get goi ng. For a RAD pr oject, i ts r ar e to need a copy of the
Mozi l l a source code.
You wi l l occasi onal l y need to peek at appl i cati on l es i n the chrome to see
how other peopl e sol ved a pr obl em youve encounter ed. I f you want to sear ch
chr ome l es effecti vel y, get one snapshot of the Mozi l l a sour ce and i ndex i t
wi th a tool l i ke UNI Xs glimpseindex(1); or just i ndex a set of unar chi ved
chrome l es.
When bui l di ng user i nter faces wi th XUL, avoi d per fecti on. I f you nd
your sel f setti ng out wi ndows to exact pi xel measur ements, you ar e doi ng i t
i ncorrectl y. Do everythi ng very roughl y, and onl y make ne adjustments at the
very end. Dont ght the tool ; use i t the easy way. I f, for exampl e, you nd that
you dont l i ke the <grid> tag, but theres nothi ng el se appropri ate, just make
do wi th <grid> anyway. Al ways di spl ay the JavaScr i pt consol e, but dont
wri te a l i ne of JavaScri pt code unti l your customer has seen the XUL screens
youve created.
When pr ototypi ng or exper i menti ng, dont be too cl ever wi th XPCOM.
Most pr ocessi ng can be handl ed just by submi tti ng an HTML for m to a Web
ser ver. Keep i t basi c, and dont tr y to master al l the XPCOM components.
Youl l never use them al l . I f you have no server, use the execute() method to
run a separate program. Dont worry about i t bei ng ugl y, you can neaten i t up
l ater.
When stuck on a techni cal pr obl em, tr y not to become di str acted by
unhel pful detai l . Most pr obl ems ar e l i ttl e mor e than syntax er r or s or mi sun-
derstandi ngs. Everythi ng i n the pl atform i s i nterpreted from XML to CSS, and
syntax er r or s cr eep i n ever ywher e. The sour ce code wi l l not hel p you wi th
thesei t takes a month of study before the source makes any sense, anyway.
The Bugzi l l a bug database (at http://bugzilla.mozilla.org) can al so be
very di stracti ng and ti me consumi ng.
A better appr oach to pr obl ems i s to make a copy of your code and chop
bi ts off unti l the probl em area i s cl ear. Then l ook at a book, or post to a news-
group. I f the probl em wont go away, at l east you have an effecti ve test case for
the Bugzi l l a database, and someone mi ght respond qui ckl y i f you l odge a bug.
I f you change your code sl i ghtl y, i t may wel l go away. Because of the pl atforms
near-zer o val i dati on behavi or and poor l y documented Mozi l l a i nter nal s, you
wont al ways have a deep r eason why some tr i vi al change made somethi ng
wor k agai n. Ther es al ways a r ati onal expl anati on, but i t often takes a l ong
ti me to nd. Move on.
I f, however, you ar e passi onate about Open Sour ce, then dont expect
wor ki ng on the Mozi l l a Pl atfor m i tsel f to be a RAD pr oject. Wor ki ng on the
pl atform i s the same as worki ng on any C or C++ project. You can make a di f-
fer ence month by month, not day by day. Unl ess you ar e l ucky enough to get
pai d for i t, i ts a ver y l ong-ter m hobby. Appl i cati ons can be r api dl y devel oped
wi th Mozi l l a, but the pl atform i tsel f i s not as easi l y devel oped.
AppDevMozilla-01 Page 26 Thursday, December 4, 2003 6:22 PM
1.6 Hands On: Cranking Up the Platform 27
1.6 HANDS ON: CRANKING UP THE PLATFORM
Thi s Hands On sessi on provi des a rst expl orati on of the Mozi l l a Pl at-
form and more steps that set up the NoteTaker project.
1.6.1 Installation
Thi s book r ecommends downl oadi ng the 1.4 r el ease of the pl atfor m, whi ch
i ncl udes Cl assi c Mozi l l a and the pl atfor m. Later r el eases ar e al so pr obabl y
ne. You mi ght want to check www.nigelmcfarlane.com for recent updates i f
thi s book has been i n pri nt a whi l e.
The i nstal l ati on notes on mozi l l a.or g ar e qui te compl ete and shoul d be
read for your pl atform. They can be revi ewed from the ofci al downl oad pages.
Some l ess obvi ous effects are bri ey covered here.
On Wi ndows 95/98/Me, your user prol e wi l l be i nstal l ed i n thi s obscure
l ocati on:
C:\Windows\Application Data\Mozilla
Under Wi ndows NT/2000/XP technol ogy, l ook i n the equi val ent path for
the current user. On UNI X, the prol e can be found here:
~/.mozilla
I ts r ecommended that you do two whol e i nstal l ati ons of Mozi l l a, each
i nto a separ ate di r ector y. One wi l l be your r el i abl e ver si on; one wi l l be for
devel opment. On Wi ndows and UNI X, i f you have onl y the defaul t user prol e,
that prol e wi l l be shared by both i nstal l ati ons. Al ternati vel y, create a di ffer-
ent prol e name for each i nstal l ati on. I f you do thi s, di sabl e emai l on the pro-
l e for the devel opment i nstal l ati on, or confusi on wi l l resul t. Two i nstal l ati ons
gi ve you two sets of chrome, one of whi ch you can experi ment on, l eavi ng the
other i ntact and worki ng.
I f you i nstal l Mozi l l a twi ce, or i f you i nstal l two versi ons, be very careful
when runni ng them together. You can tel l the di fferences between them from
the date i n the ti tl e bar (on Wi ndows), but star ti ng one when the other i s
al r eady r unni ng i s confusi ng, especi al l y dur i ng testi ng. Thi s i s because
Mozi l l a uses a si gnal i ng mechani sm. The ver si on you star ted mi ght si gnal a
r unni ng copy of Mozi l l a and then di e str ai ght away. That r unni ng copy then
opens a new wi ndow. I t l ooks l i ke you start a new wi ndow and a new i nstance
of the pl atfor m, but you r eal l y just opened another wi ndow of the exi sti ng,
r unni ng pl atfor m. I f you ar e accustomed to vi ewi ng Web pages whi l e you
devel op, then the cl eanest way to do that on Wi ndows i s to i nstal l I nter net
Expl orer as wel l . Use that for vi ewi ng documentati on. On UNI X, i t i s easy to
run separate i nstances of the pl atformjust use the command l i ne.
Thi s book assumes standar d i nstal l ati on di r ector i es. On Mi cr osoft Wi n-
dows 95/98/Me, the i nstal l di rectory i s here:
C:\Program Files\Mozilla
AppDevMozilla-01 Page 27 Thursday, December 4, 2003 6:22 PM
28 Fundamental Concepts Chap. 1
Under UNI X, i nstal l i ng appl i cati ons i nto /usr i s overrated and makes subse-
quent versi on control tasks harder. Ask any system admi ni strator. The i nstal -
l ati on di rectory i s assumed to be here:
/local/install/mozilla
I n both cases, Mozi l l as chrome i s stored i n a chrome subdi rectory underneath
these di rectori es.
I f you do two UNI X i nstal l ati ons, you need to r evi ew the i nstal l ati on
notes about setti ng the envi ronment vari abl e MOZI LLA_FI VE_HOME. I f you
want to run the program from a GNOME i con, read the i nstal l ati on notes. The
GNOME Panel i s the bar acr oss the bottom of the desktop. You can dr ag a
newl y made i con from the panel di rectl y onto the desktop.
The fol l owi ng systems wer e used to test thi s book: Mi cr osoft Wi ndows
98SE wi th I nter net Expl or er 6.0 and patches; Red Hat GNU/Li nux 7.2 wi th
GNOME 2.02. We al so bri ey tested wi th Mi crosoft Wi ndows XP and MacOS X.
1.6.2 Command Line Options
Command-l i ne hel p for the Mozi l l a Br owser i s avai l abl e on UNI X usi ng
--help. On Mi crosoft Wi ndows, -h or -help wi l l di spl ay a hel p message but
onl y i f Mozi l l as output i s sent to a l e. Tabl e 1.1 shows the avai l abl e opti ons,
but not al l are avai l abl e on al l pl atforms.
1.6.3 Chrome Directories and the Address Book
The qui ckest way to see what Mozi l l a appl i cati on devel opment i s l i ke i s to see
somethi ng wor ki ng. The Addr ess Book of Cl assi c Mozi l l a i s an easy star ti ng
poi nt. Li ke many Per sonal I nfor mati on Manager s (PI Ms), i ts just a set of
names and contact poi nts, i ncl udi ng emai l addresses. The address book i s ti ed
to the Cl assi c Mai l & Newsgr oup cl i ent, fr om whi ch i t automati cal l y col l ects
new names. I ts database of contacts al so assi sts the user when the Mai l &
Newsgroup cl i ent tri es to auto-compl ete a parti al l y typed-i n address.
Str uctur al l y, the addr ess book i s a pi ece of the Mai l & News package.
That package i s wri tten enti rel y as a RAD cl i ent, usi ng Mozi l l as chrome con-
cept. That means i t contai ns no C or C++, al though i t makes heavy use of C/
C++ XPCOM components. I t al so means that you can customi ze and r ewr i te
the i nterface of the Cl assi c Mai l & News cl i ent as you see t. The i nterface i s
wr i tten i n JavaScr i pt and XUL, pl us some compl ementar y technol ogi es. The
Cl assi c Mai l & News Cl i ent i s stored i n the chrome.
The chr ome di r ector y contai ns pl ai n textl es and JAR l es. JAR stands
for Java Archi ve. I t deri ves from Sun Mi crosystems Java project. For Mozi l l a,
such l es ar e i n pl ai n ZI P for mat on Wi ndows and UNI X. On Wi ndows, i ts
conveni ent to associ ate these l es wi th a tool l i ke Wi nZi p, or el se the Java
JVM wi l l try to execute them when they are doubl e-cl i cked. Fi l e associ ati ons
wi th Wi nZi p are a l i ttl e tri cky. I f doubl e-cl i cki ng a JAR l e zi ps i t up a second
AppDevMozilla-01 Page 28 Thursday, December 4, 2003 6:22 PM
1.6 Hands On: Cranking Up the Platform 29
ti me, then x that wi th the Wi nZi p Command Li ne Suppor t Add-on fr om
www.winzip.com . I n the absence of the add-on, just use File | Open Archive to
i nspect the JAR l e. On UNI X, zip/unzip ar e the cor r ect tool s, not gzip/
gunzip. On the Maci ntosh, StuffI t! or a si mi l ar tool i s requi red.
Fi gure 1.4 shows a typi cal exampl e of the chrome di rectory on Mi crosoft
Wi ndows.
Table 1.1 Command-line option for Mozilla
Option name Mozilla starts with
-addressbook the emai l address book
-chat the I RC chat cl i ent, i f i nstal l ed
-compose el d1=val 1,
el d2=val 2,etc
the emai l message composer
-chrome URL a chrome wi ndow, contents at URL
-consol e an addi ti onal command-l i ne wi ndow that di spl ays di ag-
nosti c messages and the output of dump()
-contentLocal e L a normal wi ndow but HTML content l ocal e set to L
-CreateProl e PNAME a normal wi ndow, under a new prol e of PNAME
-edi t URL the Composer HTML edi tor, edi ti ng the l e at URL
-h -hel phel p nothi ng; di spl ay command-l i ne hel p i nstead
-hei ght N a wi ndow N pi xel s hi gh
-i nstal l er the Netscape 4.x mi grati on tool
-jsconsol e the JavaScri pt consol e
-mai l the emai l and news reader
-news the emai l and news reader
-nospl ash wi thout the spl ash screen
-P PNAME the user whos prol e i s PNAME
-Prol eManager the prol e manager tool
-Prol eWi zard the prol e creati on tool
-Sel ectProl e the prol e sel ecti on tool
-qui et wi thout the spl ash screen
-UI Local e L a normal wi ndow but wi th the XUL l ocal e set to L
-venkman the JavaScri pt debugger, i f i nstal l ed
-wi dth N a wi ndow N pi xel s wi de
AppDevMozilla-01 Page 29 Thursday, December 4, 2003 6:22 PM
30 Fundamental Concepts Chap. 1
Thi s scr eenshot shows a Mozi l l a i nstal l ati on wi th en-US (U.S. Engl i sh,
the defaul t) and fr-FR (standard French) l ocal i zati ons. Mozi l l a auto-generated
the overlayinfo di rectory and sol i tary text l es; however, they can be edi ted
by hand.
chrome.rdf i s a text-based database of al l the JAR l es.
toolkit.jar contai ns general -purpose uti l i ti es that make up a gl obal
pi ece of chrome content.
classic.jar contai ns the Cl assi c ski n.
messenger.jar contai ns the Mai l & News Cl i ent.
comm.jar contai ns the chrome for a normal Web browser wi ndow and
for the HTML edi tor.
I t mi ght seem that some pattern i s i mpl i ed by these l e names, but that
i s not stri ctl y true. There i s merel y a JAR nami ng conventi on that keeps l an-
guage packs, themes, and components separ ate. I t i s not mandator y to use
JAR l esl es can be stor ed on thei r own, uncompr essed and un-ar chi ved,
anywhere i nsi de the chrome di rectory. A second nami ng conventi on appl i es to
the di r ector y str uctur e under neath the chr ome di r ector y. I f i t i s not appl i ed,
some featur es of the pl atfor m wont wor k, so that conventi on i s mor e i mpor-
tant. An exampl e of thi s second conventi on i s shown i n Fi gure 1.5.
Thi s chrome di rectory contai ns two appl i cati on packages, packageA and
packageB. The most i mportant di rectori es are underl i ned: content, locale,
and skin. Content contai ns the appl i cati on. Local e contai ns l anguage-speci c
Fig. 1.4 Chrome di rectory on Mi crosoft Wi ndows.
AppDevMozilla-01 Page 30 Thursday, December 4, 2003 6:22 PM
1.6 Hands On: Cranking Up the Platform 31
el ements of the appl i cati on. Ski n contai ns theme-speci c el ements of the
appl i cati on (decor ati ve i nfor mati on). By spl i tti ng an appl i cati on i nto these
three components, an appl i cati on can be reused across di fferent l anguages and
themes. Under neath these thr ee di r ector i es, subdi r ector i es can be nested as
deep as you l i ke, as the subdir exampl es show.
I f you exami ne the l es i nsi de any JAR archi ve, you wi l l see that they are
di str i buted acr oss thi s standar d di r ector y l ayout. Thus, modern.jar, a JAR
l e contai ni ng the moder n ski n, hol ds l es for the ski n subdi r ector y onl y,
whereas venkman.jar, the JavaScri pt debugger, contri butes l es to al l three
top-l evel chr ome di r ector i es. The di r ector i es i nsi de a JAR l e ar e sl i ghtl y
i nver ted so that they dont match the hi er ar chy of Fi gur e 1.5. Thi s i s done to
make searchi ng the JAR l e faster. Mozi l l a automati cal l y converts these non-
standard di rectori es back to those of Fi gure 1.5 i f necessary.
Al l these nami ng and str uctur al conventi ons can be compl etel y i gnor ed
at two costs. Fi r st, your appl i cati on i s l i kel y to become a di sor gani zed mess.
Second, chr ome URLs ar e magi cal l y modi ed to pi ck up the cur r ent theme
and cur r ent l ocal e. I f your MyTheme ski ns and MyLocal e text ar ent i n the
r i ght di r ector i es, they mi ght di spl ay because they ar e har dcoded i n, but they
wont r espond to the chr ome system when the current theme or l ocal e i s
swi tched to MyTheme or MyLocal e.
For the address book, Fi gure 1.6 shows a sl i ce of the appl i cai ton's i nsi des.
Fr om thi s scr eenshot, i ts cl ear that chr ome appl i cati ons can be l ar ge
thi s JAR l e expands to 1.5 MB (megabytes) of source code. Some JavaScri pt
scri pts i n thi s JAR l e are nearl y 100 KB (ki l obytes) al one. There i s no compi -
l ati on to do on any of these l es; they al l run i n Mozi l l a exactl y as they are.
Fig. 1.5 Chrome subdi rectori es for al l pl atforms.
AppDevMozilla-01 Page 31 Thursday, December 4, 2003 6:22 PM
32 Fundamental Concepts Chap. 1
The nearest equi val ent i n the address book to a main.c i s the address-
book.xul l e. I t i s a good exampl e of Mozi l l as featur es at wor k. I f you vi ew
thi s l e, get out your XML exper i ence, and spot the fol l owi ng gener al i tems:
XML notati on; us e of <?xul-overlay>, <?xml-stylesheet?>, and
<script> to i ncl ude other l es; extensi ve use of DTDs and enti ty references;
XML namespace decl ar ati ons; event handl er s; and a bi g pi l e of tags that
sound descri pti ve of GUI s.
Thi s JAR l e i s not the onl y one that contai ns addr ess book l es. Mor e
can be found i n other l es, such as the JAR l es hol di ng Cl assi c and Moder n
ski ns. I f you del ete al l the chrome, or wreck i t, you cant use the address book,
and may not be abl e to start Mozi l l a at al l . Chrome i s vi tal to Mozi l l a.
I ts al so possi bl e to modi fy Mozi l l a fr om outsi de the chr ome di r ector y.
Chapter 17, Depl oyment, cover s XPI nstal l , whi ch al l ows most l es i n the
Mozi l l a i nstal l ati on to be r epl aced. Some of these l es, l i ke pr efer ence l es,
make sense to modi fy, and thi s book poi nts out when that i s a good i dea. Oth-
er s, l i ke some of the r esour ce l es under the res di r ector y, ar e better l eft
al one. I gnor i ng these l es i s a good i dea because they have been thor oughl y
Fig. 1.6 Address book porti on of messenger.jar chrome l e. Used by permi ssi on of
Wi nZi p Computi ng, I nc.: Copyri ght 1991-2001 Wi nZi p Computi ng, I nc.Wi nZi pi s a
regi stered trademark of Wi nZi p Computi ng, I nc. Wi nZi p i s avai l abl e from
www.winzip.com. Wi nZi p screen i mages reproduced wi th permi ssi on of Wi nZi p
Computi ng, I nc.
AppDevMozilla-01 Page 32 Thursday, December 4, 2003 6:22 PM
1.6 Hands On: Cranking Up the Platform 33
tested. Bi nar y l es can al so be changed, but that i s a C/C++ codi ng job for
another day. Fi nal l y, there are congurabl e l es under the i ndi vi dual Mozi l l a
user prol es. The .js preference l es i n there are probabl y the onl y l es that
occasi onal l y requi re hand-modi cati on.
1.6.4 hello, world
No programmi ng book i s compl ete wi thout a go at thi s si mpl e program, made
famous by Kerni ghan and Ri tchi e i n The C Programming Language . The ori g-
i nal hello, world was upgr aded to Hello, World! after C gai ned an
ANSI standar d. Mozi l l a i s i n i ts for mati ve days, so the ear l y ver si on i s the
appropri ate one to fol l ow here.
Mozi l l a suppor ts al l the si mpl e ver si ons of HTML-based hel l o, wor l d
you can thi nk of. Ther e ar e endl ess var i ati ons. Li sti ng 1.2 shows tr i vi al ver-
si ons for l egacy and standard HTML di al ects, i n case anyone has forgotten.
Listing 1.2 hello, world in legacy HTML and in XHTML 1.0.
<html><body>
hello, world
</body></html>
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<body>
hello, world
</body></html>
For r api d appl i cati on devel oper s, a mor e appr opr i ate hel l o, wor l d uses
XUL, Mozi l l as GUI markup l anguage. Agai n, there are endl ess vari ati ons, but
the si mpl est case, whi ch reveal s very l i ttl e about XUL, l ooks l i ke Li sti ng 1.3.
Listing 1.3 hello, world in legacy Mozillas XUL.
<?xml version="1.0"?>
<!DOCTYPE window>
<window xmlns= "http://www.mozilla.org/keymaster/gatekeeper/
there.is.only.xul"
>
<box>
<description>hello, world</description>
</box>
</window>
The mai n thi ng to note i s that XUL r equi r es a speci al tag (<descrip-
tion>) wi th an i nconveni entl y l ong name for si mpl e text. XUL l es dont usu-
al l y contai n much pl ai n text; they contai n other thi ngs. The XML namespace
AppDevMozilla-01 Page 33 Thursday, December 4, 2003 6:22 PM
34 Fundamental Concepts Chap. 1
i denti er i s an obl i que reference to the movi e Ghostbusters , based on the fact
that some pr onounce XUL l i ke thi s: zool . Thi s str i ng appear s nowher e but
i nsi de Mozi l l a. Ther e i s a pl acehol der XML page at the Web addr ess gi ve by
thi s stri ng, but i t i s not used for anythi ng.
To get thi s goi ng, save the content to a l e cal l ed hello.xul i n any
di rectory. No use of chrome i s necessary for si mpl e cases. Load i t i nto Mozi l l a
usi ng a file: URL, typed i nto the l ocati on bar as for any URL. The r esul t
mi ght be as shown i n Fi gure 1.7, i f the l e were l ocated i n /tmp/hello.xul.
Mozi l l a XUL content does not have to appear i nsi de a br owser wi ndow.
Shut down Mozi l l a, and star t i t fr om the command l i ne usi ng the -chrome
opti on. A typi cal one-l i ne UNI X command i s
/local/install/mozilla/mozilla -chrome file:///tmp/hello.xul
A typi cal one-l i ne Mi crosoft Wi ndows command i s
"C:\Program Files\Mozilla\mozilla.exe" -chrome "file:C:/tmp/
hello.xul"
I n ei ther of these cases, the resul t i s l i kel y to be as i l l ustrated i n Fi gure 1.8.
Thi s l ast expressi on of hel l o, worl d i s typi cal of appl i cati ons devel oped
wi th Mozi l l a. I ts a begi nni ng.
1.6.5 NoteTaker Preparation
The NoteTaker appl i cati on i s a ti ny exampl e appl i cati on runni ng through thi s
book. Rather than standi ng by i tsel f, i t works wi th the Mozi l l a Cl assi c Browser.
When end users i nstal l NoteTaker, al l the setup i s done for them automati cal l y.
As devel opers, we must make our own road, ri ght from the begi nni ng.
Fig. 1.7 XUL versi on of hel l o, worl d di spl ayed as a document.
Fig. 1.8 XUL versi on of hel l o, worl d di spl ayed as chrome.
AppDevMozilla-01 Page 34 Thursday, December 4, 2003 6:22 PM
1.7 Debug Corner: Debugging from Outside 35
The onl y step requi red for NoteTaker setup i s to create some di rectori es
and to regi ster the name notetaker as an ofci al Mozi l l a chrome package. As
an ofci al package, i t wi l l be accessi bl e vi a the chrome: URL scheme. Her e
are i nstructi ons for creati ng the di rectori es:
1. I n the Mozi l l a i nstal l area, change the current worki ng di rectory to the
chrome di rectory.
2. Make a subdi rectory notetaker, and change to that di rectory.
3. Make subdi rectori es named chrome, locale, and skin.
4. I nsi de locale, make an en-US subdi rectory.
5. I nsi de skin, make a classic or modern subdi rectory, or both.
Package regi strati on i s done i n the chrome/install-chrome.txt l e.
To regi ster NoteTaker as the chrome package notetaker, just add thi s l i ne to
the end of that l e, and restart the pl atform.
content,install,url,resource:/chrome/notetaker/content/
Thi s syntax i s ver y fr agi l e and must be added exactl y as shown. On the
appl i cati on si de, nothi ng more i s requi red at thi s poi nt, al though wel l revi si t
these di rectori es frequentl y. I t i s recommended that you al so fol l ow the advi ce
i n the Debug Corner secti on thats next.
1.7 DEBUG CORNER: DEBUGGING FROM OUTSIDE
Mozi l l a i s qui te a compl i cated system. I f you don't have i t congured correctl y,
wor ki ng appl i cati ons ar e har der to achi eve. The number of myster i ous pr ob-
l ems i s reduced wi th every bug x, but i ts better to set yoursel f up for success
from the begi nni ng.
You can appl y a number of overal l setti ngs to Mozi l l a to make l i fe easi er.
The most obvi ous technol ogy to l earn i s the JavaScri pt debugger, code-named
Venkman. I ts l ocated under Tools | Web Development | JavaScript Debugger. I f you
l i ke vi sual , i ntegrated debuggers, then thi s i s the way to go. Thi s author pre-
fers the UNI X phi l osophy of many smal l tool s, so theres no Venkman tutori al
here. To start the debugger, add thi s l i ne to the scri pts i n your appl i cati on:
debugger;
Netscape 7.0 doesnt come bundl ed wi th the debugger (versi on 7.1 does),
but you can sti l l downl oad and auto-i nstal l i t at any poi nt. To nd i t, l ook on
the DevEdge Web si te, at http://devedge.netscape.com.
1.7.1 Important Preferences
The most i mpor tant thi ng to get r i ght i s Mozi l l as pr efer ences. Mozi l l a has
over a thousand pr efer ences. Onl y a ti ny subset ar e avai l abl e fr om the Edit |
AppDevMozilla-01 Page 35 Thursday, December 4, 2003 6:22 PM
36 Fundamental Concepts Chap. 1
Preferences menu. The r est shoul d be hand-coded usi ng a text edi tor. Mozi l l a
cannot be r unni ng whi l e doi ng thi s because i t r ewr i tes the pr efer ence l es
every ti me i t shuts down. Thi s i s the same as Netscape 4.x products.
You can al so see and edi t the majori ty of preferences by typi ng the URL
about:config. Bewar e that the edi ti ng system does not modi fy the pr efer-
ence that you ri ght-cl i ck on; i t modi es any preference. There are hi dden pref-
erences as wel l as those shown.
To change a pr efer ence on di sk, ei ther modi fy the prefs.js/prefer-
ences.js l e i n the appr opr i ate user pr ol e, cr eate a new pr efer ence l e
cal l ed user.js i n the user pr ol e, or modi fy the all.js l e under the
Mozi l l a i nstal l ar ea. That l ast l e i s i n defaults/prefs. Just dupl i cate an
exi sti ng l i ne and modi fy i t. Preference order i s not i mportant.
Tabl e 1.2 l i sts pr efer ences that, for appl i cati on devel oper s, ar e best
changed away from the defaul t.
There are numerous other dumpi ng and debuggi ng opti ons, but they are
of l i mi ted assi stance. Make sure that the normal browser cache i s set to com-
pare pages wi th the cache every ti me they are vi ewed.
You mi ght want to test your Mozi l l a appl i cati ons on Netscape 7.0 as wel l
as on the mozi l l a.org pl atform. Netscape 7.0s Qui ck Launch feature i s hard to
turn off under Mi crosoft Wi ndows. Even i f you choose no duri ng the i nstal l a-
ti on, i t may sti l l be acti vated. I f so, l ook i n the Wi ndows regi stry here for some-
thi ng to remove:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Table 1.2 Important nondefault developer preferences
Preference Set to Reason
browser.dom.wi ndow.dump.enabl ed true Enabl es di agnosti c functi on dump().
ngl ayout.debug.di sabl e_xul _cache true By defaul t your XUL appl i cati on i s
cached by Mozi l l a. Duri ng testi ng
you want the real , genui ne l e l oaded
at al l ti mes.
javascri pt.opti ons.stri ct true Adds more di agnosti c reports to the
JavaScri pt Consol e.
ngl ayout.debug.di sabl e_xul _fastl oad true A second cache for XUL, l oaded at
startup ti me from an .MFL l e. Pos-
si bl y confusi ng when l eft on.
si gned.appl ets.codebase_pri nci pal _support true Li fts al l securi ty restri cti ons on
downl oaded content except that the
user must sti l l grant access.
xul .debug.box false Can be turned on from i nsi de an
XUL l e i f requi red.
AppDevMozilla-01 Page 36 Thursday, December 4, 2003 6:22 PM
1.7 Debug Corner: Debugging from Outside 37
1.7.2 Multiwindow Development
When Mozi l l a i s r unni ng, i t gener al l y manages mor e than one wi ndow at a
ti me. I t i s easy to be confused by thi s arrangement, especi al l y i f you have mul -
ti pl e versi ons of Mozi l l a i nstal l ed.
1.7.2.1 Microsoft Windows Behavior I f a new Mozi l l a wi ndow i s opened on
Mi crosoft Wi ndows, then i t wi l l be attached to any currentl y runni ng Mozi l l a
program. That means that there can be at most one versi on of Mozi l l a runni ng
at any gi ven ti me, and at most one i nstance (runni ng executabl e) of that ver-
si on.
I f a wi ndow i s star ted fr om the command l i ne or desktop i con, then the
program executed does no more than l ook for an exi sti ng, runni ng Mozi l l a. I f
one exi sts, that exi sti ng copy i s sent an open wi ndow i nstr ucti on, and the
command l i ne or i con-based pr ogr am ends. Onl y i f ther e i s no other Mozi l l a
pr ogr am r unni ng wi l l a command l i ne or i con star t a whol e new pl atfor m
i nstance.
Thi s means that i f you have two ver si on of Mozi l l a, i n the si mpl e case,
you cant run them both at the same ti me on Wi ndows. I n the compl ex case, i t
i s possi bl e to overcome thi s restri cti on. To do so, start by maki ng a copy of the
Mozi l l a executabl e. Modi fy the copys r esour ces wi th a r esour ce edi tor tool
(e.g., Mi crosoft Vi sual C++). Change resource stri ngs 102 and 103 i n the Stri ng
Tabl e secti on to somethi ng new. Save the copy. The copy can now be r un as a
separate i nstance to the ori gi nal executabl e. I t shoul d al so use a separate pro-
l e. I f you do thi s, you al so have to remember thi s modi cati on i s i n pl ace.
Second, i t i s possi bl e (and someti me easy) to create poorl y formed XUL-
based appl i cati ons. When wi ndows hol di ng these appl i cati ons ar e di spl ayed,
ever ythi ng seems nor mal , al though they may not wor k as i ntended. I n r ar e
cases, when those wi ndows ar e cl osed, the r unni ng pl atfor m can l i nger on. I f
thi s happens, the next wi ndow opened wi l l use the exi sti ng pl atfor m, whi ch
may be i n a buggy state as a resul t of the poorl y formed appl i cati on previ ousl y
tested.
I f you suspect that thi s i s happeni ng to you, use Contr ol -Al t-Del ete to
check for any Mozi l l a pr ocesses sti l l r unni ng, even though al l wi ndows ar e
gone. Such a process i s safe to ki l l .
1.7.2.2 UNIX X11/GTK Behavior On UNI X/Li nux, a Mozi l l a command l i ne or
desktop i con wi l l not i nter act wi th an exi sti ng, r unni ng i nstance of Mozi l l a.
Thi s i s the opposi te of Mi cr osoft Wi ndows and i s tr ue for ver si ons at l east as
modern as 1.4.
Thi s behavi or i s somethi ng of a nui sance because a XUL appl i cati on does
not usual l y have standard Mozi l l a menus. These menus are the access poi nts
for di agnosti c tool s l i ke the DOM I nspector, Debugger, and JavaScr i pt Con-
sol e. Wi thout these menus, theres no obvi ous way to start these tool s. So i t i s
di fcul t to appl y them to the XUL appl i cati on under devel opment. On Wi n-
AppDevMozilla-01 Page 37 Thursday, December 4, 2003 6:22 PM
38 Fundamental Concepts Chap. 1
dows, you can just star t another Navi gator wi ndow and open the standar d
menus from there. On UNI X, you cannot.
There i s a very easy workaround for the JavaScri pt consol e; just add thi s
opti on to the command l i ne:
-jsconsole
A mor e gener al wor kar ound i s to i ncl ude a pi ece of scr i pt i n your XUL
appl i cati on, as shown i n Li sti ng 1.4. For thi s scri pt to work, the XUL appl i ca-
ti on must be i nstal l ed i n the chr ome, si nce i t r equi r es that no secur i ty be i n
pl ace.
Listing 1.4 Starting Mozilla tools with an application.
<script>
var options =
"chrome,extrachrome,menubar,resizeable,scrollbars,status,toolbar
";
var domins = "chrome://inspector/content/inspector.xul";
var jscons = "chrome://global/content/console.xul";
if (window.name == "_blank") {
setTimeout("window.open('"+location+"','test','chrome')",5000);
setTimeout("window.close()",6000);
window.open(domins,"_blank",options);
window.open(jscons,"_blank",options);
}
</script>
Thi s scri pt opens the DOM I nspector and JavaScri pt Consol es when the
current document l oads and then repl aces the current document wi th an i den-
ti cal copy i n another wi ndow. Thi s l ast step i s done so that the appl i cati on wi n-
dow l oads l ast. Thi s l oadi ng or der al l ows the DOM I nspector to noti ce the
appl i cati on wi ndow, whi ch can then be i nspected.
There are many systems between Mozi l l a and the screen under UNI X. I f
you exper i ment aggr essi vel y wi th the appl i cati on, i ts possi bl e to tr i p over
bugs hi di ng el sewhere i n the desktop. I f somethi ng l ocks up or goes mad, the
r st thi ng that attr acts bl ame i s Mozi l l a, but the bl ame may wel l l i e el se-
wher e. Use top(1), ps(1), and kill(1) to shut down and r estar t one sys-
tem at a ti me unti l the probl em i s gone. A sui tabl e testi ng order fol l ows:
1. Ki l l and restart al l Mozi l l a processes and cl ean up XUL .mfasl l es, i f
any.
2. Ki l l and restart the wi ndow manager (sawsh, twm, enl i ghtenment,
etc.).
3. Ki l l and restart the whol e desktop (GNOME, KDE, OpenStep, etc.).
4. Ki l l and restart the X-server (Xfree86, vncserver, etc.).
5. Logout and l ogi n.
6. Reboot the computer.
AppDevMozilla-01 Page 38 Thursday, December 4, 2003 6:22 PM
1.8 Summary 39
Such pr obl ems ar e r ar e, but a systemati c appr oach to sol vi ng them wi l l
save a great deal of ti me. I t wi l l al so save Mozi l l a from an undeserved bad name.
1.7.3 Compile-Time Options
I f you are wi l l i ng to wrestl e wi th the compi l ati on process for Mozi l l a, you can
bui l d a bi nary wi th addi ti onal programmer-l evel debuggi ng support. Some of
thi s support can be acti vated by setti ng vari ous magi c envi ronment vari abl es.
Be warned that some of these opti ons spew out vast amounts of i nformati on.
The gateway to a more debuggabl e versi on of Mozi l l a i s the --disable-
debug opti on. Thi s i s an opti on to the configure tool set ri ght at the start of
the compi l e process. When turned on, many secti ons of debug code throughout
Mozi l l a ar e i ncl uded i n the compi l ed code. To tur n thi s opti on on, or to tur n
other opti ons on, you can gener ate a custom l e that configure can take
advantage of fr om a for m on mozi l l a.or g. That for m i s l ocated at http://
webtools.mozilla.org/build/config.cgi.
To understand what envi ronment vari abl es make secti ons of debug code do
somethi ng, read the Mozi l l a source code. To nd other debug assi stance at the
compi l e l evel , such as #ifdef EXTRA_DEBUG di recti ves, read the source code.
1.8 SUMMARY
Mozi l l a i s a br owser-l i ke tool that can be used to cr eate appl i cati ons faster
than tr adi ti onal 3GLs (Thi r d-Gener ati on Languages). I t br i ngs some of the
benets of Web-based appl i cati ons to tradi ti onal GUI -based appl i cati ons. The
hi ghl y i nter pr eted natur e of such envi r onments cr eates an oppor tuni ty to do
ver y r api d i ter ati ve devel opment and efci ent pr ototypi ng. Thi s efci ency
must be bal anced agai nst a desi re to l ook more deepl y i nto the tool , whi ch i s a
ti me-consumi ng acti vi ty, and agai nst syntax pr obl ems, whi ch r est heavi l y on
the shoul ders of the devel oper.
Mozi l l a has i ts r oots i n the evol uti on of Web br owser technol ogy, and i t
has much to offer i n that ar ea. I t has up-to-date standar ds suppor t and i s
hi ghl y portabl e. For UNI X pl atforms, i t i s the obvi ous, i f not the onl y, browser
choi ce. The archi tectural extensi ons i nsi de Mozi l l a, however, are of most i nter-
est to devel oper s. The componenti zati on of Mozi l l as i nter nal s pr esents a
devel oper wi th a ready-made set of servi ces to work wi th, and i nnovati ve GUI
markup l anguages l i ke XUL are powerful and conveni ent. Thi s pi ece-by-pi ece
structure al l ows Mozi l l a to be consi dered a devel opment pl atform, al though i t
suffers a l i ttl e from bei ng versi on 1.0.
Mozi l l a i s backed by an organi zati on that i s both commerci al l y and com-
muni ty dr i ven. I t pr ovi des a pl ethor a of r esour ces for a techni cal per son to
take advantage of and asks nothi ng i n r etur n. The or gani zati on has many
par tner s i n commer ce, academi a, and standar ds communi ti es and shows no
si gn of shutti ng up shop. I t seems l i kel y that the technol ogy i t devel ops has a
fai r chance of bei ng useful , i nuenti al , and popul ar.
AppDevMozilla-01 Page 39 Thursday, December 4, 2003 6:22 PM