Chapter 12. Remote Applications-P2

12.4.1.1. PHP
When users of your application may not have configured their browser to
support the correct MIME type, you can use the PHP header function to send
the browser the correct type.
Remember that when using XUL with PHP, you need to edit your php.ini
file on the server and change the default configuration to:
short_open_tag = Off
By default, this configuration is set to "On." When "Off," this setting tells
the PHP interpreter to parse only the files with escape tag identifiers, such as
<?php ?> (and not <? ?>, which are used by XML). This process is
separate from the XML parsing process that occurs when Mozilla receives
and tries to render the generated content. If you don't change the .ini file,
you will see an error like this:
Parse error: parse error in
/usr/local/share/doc/apache/remote_xul.php on line
2
This error occurs when PHP sees your XUL syntax as invalid PHP code.
Once PHP is properly configured to handle XUL files, you're ready to go.
To start out with something simple, use the code in Example 12-4
to produce
a simple XUL window with the xFly logo by using PHP. Be sure to save the
file with a .php extension.
Example 12-4. Using PHP to generate the correct XUL MIME type
<?php header( "Content-type:
application/vnd.mozilla.xul+xml" ); ?>
<?xml version="1.0"?>
<!DOCTYPE window>
<window
id = "remote"

you're all set. Otherwise, you should grab a distribution of Perl
( and set up the paths to the binary files in your server
scripts. This procedure is done by placing the path in the header, otherwise
known as the shebang line. This script usually takes a form similar to
#!/usr/local/bin/perl or #!/usr/bin/perl. You must also
make sure that the server knows where the Perl executable is, which
involves including the path to it in the systems PATH environment variable.
Depending on the platform and the web server you use, other environments
may need to be set.
Example 12-5 shows a simple CGI script that generates a minimal amount of
XUL for display in the browser. Perl is useful for this task because you can
set up several possible scripts and call selected ones, depending on what
choices the user makes. You can even have different forks in the same script
that displays different widgets or data. For example, imagine that your
remote XUL application is an online travel planner. You would display
maps, information, and links to resources based on the user's geographic
location or preferences for destinations they entered earlier.
Example 12-5. A simple Perl-generated XUL file
#!/usr/bin/perl
print "Content-type:
application/vnd.mozilla.xul+xml";
print qq{
<?xml version="1.0"?>
<!DOCTYPE window&gt;
<window
id = "remote"
xmlns = "
style = "min-width:282px; min-height:137px;"
orient = "vertical">


<?xml version=\"1.0\"?>
<!DOCTYPE window>
<window
id = "remote"
xmlns =
" />is.only.xul"
title = "listbox"
style = "min-width:282px; min-height:137px;"
orient = "vertical">
<box>"""
print ' <checkbox label="%s" />' %
form['op1'].value
print ' <checkbox label="%s" />' %
form['op2'].value
print ' <checkbox label="%s" />' %
form['op3'].value
print """</box>
</window>"""
In this example, the CGI module is loaded with the Python import
statement, and the form object is initialized so that data input to the page in
the form of URL ?name=value pairs create the XUL content dynamically.
Example 12-6
takes a URL, such as />bin/xulgen?opt1=peter?opt2=paul?opt3=mary, and displays a checkbox for
each value of the named form fields. The content type is printed before the
XUL content to tell the web server what to pass when the script produces its
output.
12.4.2. Generating Content from a Database
One of the important facets of dynamically generated content is interaction
with a database to store and retrieve values for the user. For example, a
public forum or subscription-based service could have a client that is written

Example 12-8. XUL generated from database
<?php header( "Content-type:
application/vnd.mozilla.xul+xml" ); ?>
<?xml version="1.0"?>
<?php
// connect code
$host = "127.0.0.1";
$user = "nobody";
$database = "test";
$password = "mypass";
$connect = mysql_connect($host, $user,
$password);
mysql_select_db($database);
$query = "SELECT * FROM sample ORDER BY
User";
$result = mysql_query($query, $connect);
$e = mysql_error( );
if($e)
print "ERROR:projects: $e";
$row = mysql_num_rows($result);
?>
<!DOCTYPE window>
<window
id = "remote"
xmlns =
" />is.only.xul"
title = "A Remote Image" style = "min-
width:282px; min-height:137px;">
<image
/>

</hbox>
</window>
The PHP header method is placed at the top of the file to properly format the
output as XUL. The PHP MySQL APIs prepare the code for connection to a
MySQL database. Finally, a loop is used to print out the stored data's
treerows and treecells.
This kind of operation provides insight into the possibilities of using remote
XUL when you have information stored in a database. Many web
applications already do this via HTML forms and other mechanisms, but
Mozilla's XPFE toolkit provides a richer widget set than HTML to display
and retrieve information (see the section Section 3.6
).
Some XUL widgets are created specifically to display complex tabular data
such as <tree>, and some widgets provide user selection such as
<checkbox>, <radio>, and <textbox>, plus the CSS used for
controlling presentation. All of these widgets can be generated on the fly
from the database and used to accept user-inputted information.
12.4.3. Localizing Remote Applications
Unfortunately, localizing remote applications is a not as straightforward
since there is no http: protocol equivalent for chrome:-included locales.
You could use HTTP/1.1 content negotiation to serve the users-preferred
language, but Mozilla 1.0 does not read DTD files over the wire. To
overcome this problem, use server-side page processing. For example, this
code includes the DTD by using PHP:
<!DOCTYPE window [
<?php
require(PROJECT_PATH."/online/locale/xfly.dtd"); ?>
]>
Therefore, the served page looks like this:
<!DOCTYPE window [

Object Signing certificate is what matters for signed applications.
Fortunately, to get your remote applications signed by a CA, you don't have
to pay for a Verisign Netscape Object Signing CA because other options are
available. You can use the MozDev CA, for example, and even create your
own. The next section tells you how use Mozilla tools to become your own
certificate authority so you can sign your own applications and those of
other Mozilla developers. The Section 12.6 section later in this chapter uses
the MozDev CA to discuss both avenues.