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 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 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="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"/> <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 http://games.mozdev.org/action/snake/. 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 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 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: [...]... http://my.domain /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... 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 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. .. 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... "A Remote Image" style = "min-width:282px; min-height:137px;" orient = "vertical"> You can now view this window by launching it as a chrome file from Mozilla as follows: /mozilla -chrome http://my.domain /remote. xul Or you can also load it up by simply entering the URL in your browser location bar as follows:: http://my.domain /remote. xul... 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 . Chapter 12. Remote Applications- P1 Remote applications developed with Mozilla use an application without having to endure a full. update the projects so everyone can enjoy them. 12. 3. Setting Up XPFE for Remote Applications Remote Mozilla applications are limited because they cannot