Home arrow Web Standards arrow Page 4 - Configuring Firefox for Chrome and a Server
WEB STANDARDS

Configuring Firefox for Chrome and a Server


If you have been building Internet applications with XUL, you'll appreciate this four-part article series. It explains how to prepare such an application for a commercial setting. This article is excerpted from chapter four of Programming Firefox, written by Kenneth C. Feldt (O'Reilly, 2007; ISBN: 0596102437). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

Author Info:
By: O'Reilly Media
Rating: 5 stars5 stars5 stars5 stars5 stars / 4
June 05, 2008
TABLE OF CONTENTS:
  1. · Configuring Firefox for Chrome and a Server
  2. · Running as a Local Installation
  3. · Package Registration
  4. · Configuring the Server

print this article
SEARCH DEVARTICLES

Configuring Firefox for Chrome and a Server - Configuring the Server
(Page 4 of 4 )

We first must install a web server on our local machine; for this application we install Apache. Once the web server is installed and running, we should see the startup page shown in Figure4-6 when we enter http://localhost/ in a browser’s URL field.

Apache is managed through the text file httpd.conf. On Unix systems, this is located in the /etc/http/ directory, whereas Windows systems will put this file in Apache’s conf directory. You can edit the file using a text editor.


Figure 4-6.  Apache startup page

The DocumentRoot directory is used to select the home directory for serving web pages. That entry, in httpd.conf, is operating-system-specific, and depends on the options we have specified during the installation:

  DocumentRoot "<YourApacheDocumentRoot>"

If the installation was performed correctly, an entry should provide Apache with information about the directories served:

  <Directory "YourApacheDocumentRoot">

Although we don’t need to make any changes to the httpd.conf file, we must note what these entries are in order to place our Common Gateway Interface (CGI) scripts in the correct directory. We will use the PHP scripting engine to provide the logic for our CGI.

We can install the PHP binaries into any directory. In a Windows environment, an example would be C:\php\, whereas a Unix install may be in /usr/local/php/. Regardless, we must make changes to Apache’s httpd.conf to properly serve PHP-generated output.

Depending on the version of PHP installed, entries in Apache’s configuration file will take one of two forms. In the first:

  LoadModule phpn_module " <YourPHPInstallDirectory> "

n  may be the version of PHP being installed.

The second form would instruct Apache to use an external configuration file to load the PHP libraries:

  Include <YourPHPInstallDirectory>/httpd.conf.php

Regardless of the particular PHP version and operating system, we can check the installation by using a text editor to write a simple PHP script to echo version information:

  <?php
phpinfo();
?>

Save the preceding text as test.php in your Apache document root directory:

  <YourApacheDocumentRoot>/test.php

Now type the URL into a browser to yield a page that looks like Figure4-7.


Figure 4-7.  Testing PHP installation

With a PHP engine running on our server, we can now conduct some simple connection tests between our application and the server.

The Client/Server Protocol

This approach will use the XMLHttpRequest object to send inquiries to our PHP server, and PHP scripts to return textual responses to the client.

ConventionalPOSTmessages from a browser to a server result in the server generating an entire page to be displayed by the browser. This process is what causes many web applications to “freeze up” after the user presses a form submission button and waits for a response.

We will first use a simpler protocol to issue a request for data resembling “classic” client/server operations. The server provides only data; the client determines what to do with the data and how to render the interface.

We can write a JavaScript function to receive the server data and format HTML table data with responses, populate text areas, or otherwise modify the GUI without forcing a complete redraw of the page. For many applications that require only a partial update of the screen, this asynchronous approach reduces the waste incurred by conventional page-based updates.

Please check back next week for the continuation of this article.


DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

blog comments powered by Disqus
WEB STANDARDS ARTICLES

- Mozilla Popcorn Maker 1.0 Makes Videos More...
- Completing a Configuration for Chrome and a ...
- Getting Connected with Firefox and Chrome
- Configuring Servers and Databases with Chrome
- Configuring Firefox for Chrome and a Server
- Designing the Elements of a Web Page
- Matching div heights with CSS and JavaScript
- Forms
- Get Down With Markup
- If I Said You Had a Beautiful Body...
- Web Standards in Dreamweaver Part 3
- Web Standards in Dreamweaver, Part 2
- Web Forms
- Making Lists Using XHTML
- Web Standards in Dreamweaver, Part 1

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials