Tài liệu Creating Applications with Mozilla-Chapter 12. Remote Applications-P1 pdf

Chapter 12. Remote Applications-P1
Remote applications developed with Mozilla use an application without
having to endure a full download process. Given the fundamental similarities
of Mozilla and standard web content, a remote Mozilla application can work
much like a regular web page. For example, you can point people to your
project at and if they use Mozilla
(or a browser that is built with Mozilla, such as Netscape 7), the browser
window becomes the application. Serving an application in this way allows
you to use most features of a locally installed Mozilla program and gives
you unique options that aren't otherwise available. These options are
discussed in this chapter.
This chapter explores this alternative distribution method and compares it to
how an installable application is built. Generally, there is no difference
between these two types of applications other than how they are delivered.
However, you should be aware of the difficulties encountered when using
remote applications.
One of the most important aspects of remote applications for Mozilla is the
XPFE environment, or more specifically, the use of XUL/XBL, JavaScript,
and CSS. Using the XPFE in remote application development offers more
possibilities than, for example, just embedding Gecko into your application.
It is the focus of this chapter.
12.1. Directions in Remote Application Development
Currently, remote Mozilla applications are not prevalent because
development focuses on making the client applications as stable and
efficient as possible. Therefore, this area of Mozilla development is largely
speculative. This chapter argues that remote applications are worth looking
at more closely.
One advantage a remote Mozilla application has over a client application is
that a developer doesn't have to worry about an installer. Also, all users have
access to the latest version of your application. Because the application is
stored centrally on a server instead of on the local computer of everyone

who tries your program, when you update it, you make an update available
to all users.
Remote software applications might be hosted in a centralized point on the
network, on multiple nodes, or on any random node in a Peer to Peer (P2P)
fashion. It's even possible to have a whole suite of remote Mozilla
applications hosted on several computers combined into one coherent
package. Figure 12-1
shows one scenario for a simple distributed Mozilla
application.
Figure 12-1. Distributed remote Mozilla application

Currently, one of the remote application's biggest disadvantages is that it has
very restricted JavaScript privileges. Here, privileges refer to the ability to
carry out certain functionalities on the local system. As many high-profile
"worm" viruses emerge routinely these days, security restrictions on
downloadable scripts and applications are understandable. Some of the most
high-profile malicious scripts access the local file system. This is not a
problem unique to the Mozilla environment, but it is something to be aware
of when planning and implementing a remote application.
To improve security, Mozilla automatically limits what JavaScript has
access to on your computer when the executed scripts come from a computer
other than the local one. One workaround uses signed scripts, as described in
the Section 12.6
section later in this chapter. You can also have users set a
special preference to enable universal XPConnect privileges to both local
and remote files. To learn how to open up the security sandbox in this way,
see the section Section 12.7
later in this chapter.
12.2. Basic Remote Application Example
The simple XUL file in Example 12-1

uses the user's local skin information
to create a toolbar-type interface for a file that can be loaded from the server.
This successful effect depends on whether your server is configured with the
correct Multipart Internet Mail Extension (MIME) type (see the later section
Section 12.3.1
). The id on the buttons are taken from the navigator skin, so
the look of the remote file changes when the user switches themes and
remains consistent with the look of the browser itself.
Example 12-1. Remote XUL example
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/"
type="text/css"?>
<?xml-stylesheet href="chrome://navigator/skin/"
type="text/css"?>
<window id="remote_example"

xmlns=" />there.is.only.xul"
title="Simple Remote Example">
<hbox>
<button label="XFlies" class="button-toolbar"
id="page-proxy-button"/>
<button label="Reptiles" class="button-toolbar"
/>
<button label="Bugs" class="button-toolbar" />
</hbox>
</window>
As you can see in Example 12-1
, the markup of a remote XUL file is like
that of a XUL file that is part of a local system's installed application. Figure
12-2 shows the XUL file presented using both Classic and Modern themes.

Figure 12-2. Remote XUL file-accessing skin

The XUL in Example 12-1
is minimal, but it does show that the
chrome:// URLs are accessible to the remote file and that the CSS and
image resources available in the chrome's skin subdirectories can be
accessed remotely. The image on the first button is picked up from a local
JAR file, as accessed through chrome by using the button's page-proxy-
button id. A more elegant application would use toolbars, menus, and
other widgets to create a full-featured application UI.
12.2.1. Case Study: Snake (a.k.a. Hiss-zilla)
In this section, we look at an application that is stripped down and based on
a basic concept but still useful. This application shows the potential of
remote application development. This case study discusses a full-featured
game that is played over the Internet. Figure 12-3
below shows a sample
screenshot of Hiss-zilla.
Figure 12-3. Hiss-zilla, a remote game

A direct link to a remote XUL file provides access to the game, as seen in
the location bar of the browser in Figure 12-3
. The game's rules are
straightforward. Click on the New Game button or use N on the keyboard to
begin, use arrow keys to change direction, and use the character P to pause
the game. To play a game of Hiss-zilla or to take a closer look at the code,
see the project page
The complete package includes all files associated with an XPFE
application, including a XUL file, a stylesheet, images, and JavaScript files.
The files and their descriptions are as follows:
snake.xul

Contains the window definition and the top level of the application
with the game grid, visual text, and application buttons.
snake.js
Contains the functionality for the game including the snake's
movement and the eating of the food.
snake.css
Contains styling for the UI features and inclusion of some images.
screen.js
Enables full screen mode in the game.
Image files
Miscellaneous images that represent parts of the snake's body as it
moves in different directions and the food that it eats.
The Snake application will be developed further later in the chapter in the
context of signed scripts. You will see new features that allow you to run the
game in full-screen mode and to store the scores. These features illustrate
different concepts relevant to remote applications.
Mozilla Gaming
Hiss-zilla is not the only example of a game created with Mozilla. Others,
such as Mozinvaders, Mozteroids, PAGMAN, and Xultris use JavaScript
and Mozilla's rendering engine to recreate two-dimensional arcade games
from the 80s and early 90s. Links to most games are available at

Many of these games were created to see how far the application
development capabilities of Mozilla could be pushed. PAGMAN in
particular was designed as a test case to see what was possible; the result
was almost identical to the original PacMan game. The creation of
PAGMAN was documented in an article that provides more information
about how the game came about and was developed. You can find the
Building a Game in Mozilla article at
/>me.html.

Although all of these games are freely available as open source projects, not
all of them work with Mozilla 1.0. Many were created while Mozilla was
still in development, so games that worked on pre-1.0 releases of Mozilla
need additional development to work today. The good news is that if you are
just dying to play Mozteroids or Xultris, you can take what you have learned
in this book and update the projects so everyone can enjoy them.
12.3. Setting Up XPFE for Remote Applications
Remote Mozilla applications are limited because they cannot access and use
some of the rich functionality provided in XPCOM interfaces. Unless you
make the privilege change described in this section, access to XPCOM via
XPConnect in your web page or remote application is forbidden. This
privilege modification set up by the remote application developer grants
complete access to the Mozilla functionality, to resources in the chrome, and
to the host system via the Mozilla components that handle such tasks as File
I/O. Of course, making this change means that the files on your server could
be read, written to, or deleted, which is why rights are restricted by default.
We recommend that you grant this extended privilege only when you do not
have valuable data on the server or if you have taken steps to ensure that the
data cannot be accessed.
The privilege, called Universal XPConnect, can be turned on from the
Privilege Manager, which is a property of the netscape.security
object. Example 12-2
shows a script that turns this privilege on and then
uses new found privilege to create XPCOM component instance.
Example 12-2. Enabling universal XPConnect
<script type="application/x-JavaScript">
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalXPConnect");
var Simple=new
Components.Constructor("@mozilla.org/js_simple_comp

onent;1", "nsISimple");
var s = new Simple( );
for(var list in s)
document.write(list+"<br>\n");
</script>
You can also turn on this privilege in your profile user preference file with
the following line:
enablePrivilege("UniversalXPConnect");

A script with this kind of plate-cleaning power can only be run
successfully when it's executed locally, as from a local XUL file with a
<DEFANGED_script> element. To open up XPConnect remotely
with JavaScript like this, you have to use a signed script (see the section
Section 12.6
in this chapter).
Once this privilege is enabled, remote XUL applications can run as if they
are local. Remote files can use any Mozilla component, reuse skin resources,
XBL widgets, and whatever else the browser uses.
12.3.1. Server Configuration
Proper configuration of the XUL MIME type on your web server is
necessary to serve remote Mozilla applications successfully. The trick is to
ensure that the server recognizes the XUL file type and knows how to serve
it properly. By default, most web servers serve files with such unrecognized
extensions as text/plain. By adding the type
application/vnd.mozilla.xul+xml to your server's
configuration, you can make sure that the server matches the file extension
and sends this MIME type in the HTTP header to the browser. To serve up
static XUL pages from your web server, you need to add this line to your
mime.types file if it hasn't been added already:
application/vnd.mozilla.xul+xml <TAB> xul

This is how you can configure Apache MIME types to serve static XUL
pages. Note that the mime.types file requires that you separate the type
from the suffix. The format is:
mime type <tab> extension.
After the type is added to the server, the browser recognizes this header as
an XUL file and parses, renders, and creates the appropriate DOM. If your
server isn't configured to recognize this MIME type, then users see the
contents of your file as source only a plain text complete with all the
formatting.
Now that your web server is configured correctly, you can add a sample
XUL file (such as the file in Example 12-3
) to your web site to make sure
things are running properly. You should name the file remote.xul and
save it in your web site's root directory for testing.
Example 12-3. A sample static XUL file
<?xml version="1.0"?>
<!DOCTYPE window>
<window
id = "remote"
xmlns =
" />is.only.xul"
title = "A Remote Image"
style = "min-width:282px; min-height:137px;"
orient = "vertical">
<image
src="
/>
</window>
You can now view this window by launching it as a chrome file from
Mozilla as follows:

./mozilla -chrome ain/remote.xul
Or you can also load it up by simply entering the URL in your browser
location bar as follows::
ain/remote.xul
12.3. Setting Up XPFE for Remote Applications
Remote Mozilla applications are limited because they cannot access and use
some of the rich functionality provided in XPCOM interfaces. Unless you
make the privilege change described in this section, access to XPCOM via
XPConnect in your web page or remote application is forbidden. This
privilege modification set up by the remote application developer grants
complete access to the Mozilla functionality, to resources in the chrome, and
to the host system via the Mozilla components that handle such tasks as File
I/O. Of course, making this change means that the files on your server could
be read, written to, or deleted, which is why rights are restricted by default.
We recommend that you grant this extended privilege only when you do not
have valuable data on the server or if you have taken steps to ensure that the
data cannot be accessed.
The privilege, called Universal XPConnect, can be turned on from the
Privilege Manager, which is a property of the netscape.security
object. Example 12-2
shows a script that turns this privilege on and then
uses new found privilege to create XPCOM component instance.
Example 12-2. Enabling universal XPConnect
<script type="application/x-JavaScript">
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalXPConnect");
var Simple=new
Components.Constructor("@mozilla.org/js_simple_comp
onent;1", "nsISimple");
var s = new Simple( );

for(var list in s)
document.write(list+"<br>\n");
</script>
You can also turn on this privilege in your profile user preference file with
the following line:
enablePrivilege("UniversalXPConnect");

A script with this kind of plate-cleaning power can only be run
successfully when it's executed locally, as from a local XUL file with a
<DEFANGED_script> element. To open up XPConnect remotely
with JavaScript like this, you have to use a signed script (see the section
Section 12.6
in this chapter).
Once this privilege is enabled, remote XUL applications can run as if they
are local. Remote files can use any Mozilla component, reuse skin resources,
XBL widgets, and whatever else the browser uses.
12.3.1. Server Configuration
Proper configuration of the XUL MIME type on your web server is
necessary to serve remote Mozilla applications successfully. The trick is to
ensure that the server recognizes the XUL file type and knows how to serve
it properly. By default, most web servers serve files with such unrecognized
extensions as text/plain. By adding the type
application/vnd.mozilla.xul+xml to your server's
configuration, you can make sure that the server matches the file extension
and sends this MIME type in the HTTP header to the browser. To serve up
static XUL pages from your web server, you need to add this line to your
mime.types file if it hasn't been added already:
application/vnd.mozilla.xul+xml <TAB> xul
This is how you can configure Apache MIME types to serve static XUL
pages. Note that the mime.types file requires that you separate the type

from the suffix. The format is:
mime type <tab> extension.
After the type is added to the server, the browser recognizes this header as
an XUL file and parses, renders, and creates the appropriate DOM. If your
server isn't configured to recognize this MIME type, then users see the
contents of your file as source only a plain text complete with all the
formatting.
Now that your web server is configured correctly, you can add a sample
XUL file (such as the file in Example 12-3
) to your web site to make sure
things are running properly. You should name the file remote.xul and
save it in your web site's root directory for testing.
Example 12-3. A sample static XUL file
<?xml version="1.0"?>
<!DOCTYPE window>
<window
id = "remote"
xmlns =
" />is.only.xul"
title = "A Remote Image"
style = "min-width:282px; min-height:137px;"
orient = "vertical">
<image
/>
</window>
You can now view this window by launching it as a chrome file from
Mozilla as follows:
./mozilla -chrome ain/remote.xul
Or you can also load it up by simply entering the URL in your browser
location bar as follows::

ain/remote.xul
12.4. Generated Content
Today part of the Web is driven by dynamically generated content. This
content is primarily stored in databases, which is used by an application or
middle layer to format the data to HTML. The web server then sends the
content to the browser. The browser receives the web page as the end result
and has no knowledge that the page was generated on the server just that it
is a properly formatted HTML file. By using these same conventional
principals, we can send generated or database-driven XUL, CSS, or
JavaScript to Mozilla. Because XUL is a document that creates a UI, this
widget drawing capability opens up a whole new world to web application
development.
If you are a web developer creating database-driven applications, you will
quickly see the limitations of using a simple markup like HTML for
example, being constrained to the content area of a browser for which you
cannot manage all of the application interface's "real estate." Using a
browser window for your application is a common enough practice, but you
still don't have the application-level widgets of most client-side applications
when you use HTML. This section shows that using XUL files created by
scripting languages allows you to create windows and applications that
move out of the browser window and into the full-featured application
space. Mozilla's origins, after all, are as a web browser and suite of Internet
applications, and the latest technologies in the XPFE toolkit go that extra
step to allow the presentation of UI information over the wire.
12.4.1. Generating Content with Scripting Languages
This section discusses the basic mechanics of server-generated content. In
most cases, the actual content is static although the server application
creates the page dynamically, the content itself is not input. It is also not
created dynamically by other methods, such as using JavaScript to
manipulate the client's document after it loads from the server.

To generate server-generated content, you need to use a scripting language.
We explore the use of three different options: PHP, Perl, and Python. PHP is
probably the most natural language for this application because it has its
origins in serving up dynamic HTML, but you can play around with your
favorite language and determine whether it has the appropriate capabilities
for this environment. To use various scripting languages with Mozilla, you
need a working knowledge of their capabilities; the scope of this book
doesn't provide programming information for the selected scripting
languages.