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

Remote Applications-P1 Remote applications developed with Mozilla use an application without having to endure a full download process.. Directions in Remote Application Development Curr

Trang 1

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 http://www.foobar.com/myApp.xul, 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

Trang 2

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

Trang 3

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"?>

Trang 4

<?xml-stylesheet href="chrome://global/skin/"

type="text/css"?>

<?xml-stylesheet href="chrome://navigator/skin/" type="text/css"?>

<window id="remote_example"

xmlns="http://www.mozilla.org/keymaster/gatekeeper/ there.is.only.xul"

title="Simple Remote Example">

<hbox>

<button label="XFlies" class="button-toolbar"

id="page-proxy-button"/>

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

Trang 5

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

Trang 6

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 http://games.mozdev.org/action/snake/

Trang 7

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,

Trang 8

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

http://games.mozdev.org/

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

http://www.oreillynet.com/pub/a/network/2000/06/30/magazine/mozilla_ga 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

Trang 9

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

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:

Trang 10

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:

Trang 11

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 =

"http://www.mozilla.org/keymaster/gatekeeper/there is.only.xul"

title = "A Remote Image"

style = "min-width:282px; min-height:137px;" orient = "vertical">

<image

src="http://books.mozdev.org/screenshots/logo5.gif" />

Trang 12