Connecting XUL Applications with PHP
Connecting XUL Applications with PHP |
||||||||
This article is introduces some of the technical aspects of getting XUL clients hooked up with PHP, based on the authors practical experience of building XUL user interfaces. |
||||||||
If you don’t know what XUL is and need an introduction, the article XUL: Rendering GUI’s with PHP may be a good place to start. It gives a good introduction to XUL, its background and its uses. So, you have looked at XUL and think it’s pretty cool stuff. But, you hate programming with javascript and are stuggling to leverage the power of your favorite scripting language, PHP. There are ways around this, but the minefield of the Gecko security model is a little to much work to figure out. Well, hopefully after reading this, you will be able to create PHP applictions that can be supplemented by the use of a XUL interface, or even a standalone XUL application that uses PHP as a server backend. To start off with, we need a simple XUL file that contains a form. This form could consist of anything, but for this example, I will be using a simple Login form that is familiar in many web applications. Some of the XUL has been left out to save space. The entire file is included in the attachment. The XUL file
Not too hard to read - we’ve all seen HTML that makes less sense. The PHP Server
Note the <pre> tags aren’t needed around the print_r’s because javasript does not squish whitespace like browsers do. Pay attention (when running this example yourself) to what’s happens to the $_COOKIE and $_SESSION variables above. The session name (XULSession) turns up in the $_COOKIE array. In other words the XUL client is doing the same as a browser does between requests (via the XMLHttpRequest object - see below). Also if you enter the username as “root” password as “topsecret” these will show up in the $_SESSION array on the next request (you need to “login” a two times to see this). In other words you can use PHP’s sessions to lock the remote XUL client out of your PHP application until a valid username and password is provided. Users will still have the remote client running (unlike normal browser clients where’s you’d probably send an HTTP redirect to an HTML login form) but as long as you keep the real Business Logic in PHP, requiring a valid session to execute it, there should be no real issues here. The XUL client will simply be “dumb and pretty” unable to do any harm. The Javascript File
Running the script
Next, his the ‘Sign in’ button and witness the response from the server.
How it works After the “Sign in” button is clicked, the doLogin method in main.js is called. In it, the username and password have been pulled from the XUL form via the Javascript DOM. For more information on the methods available via DOM, take a look at some of the links in the references at the end of this article. After we have pulled in the username and password into scope, a new ‘phpRequest’ object is instantiated. The phpRequest is a javascript object that takes care of the nasty details of connecting and talking to a PHP server. More on that later in the article. The add() function simply takes a key/value pair that contains data that will be sent to the php script. After all key/value pairs have been added to the request, the execute method is called and the request is actually made to the the server. The entire HTTP response body is returned by the execute method. The response is then echoed to the screen to provide feedback that our method actually worked. A word about security In other words: The second way to connect to a remote server would be to install your XUL package into your local chrome directory. When you install the package locally, you can connect to any server via an absolute URL. More information about the javascript security model can be found on the web. The phpRequest object The (tammairanslip)
Javascript’s object model is a little screwy. Instead of defining a ‘class’ in php, you create functions and then link them together. That is what is happening in the phpRequest function. Several variables are set including the server URL that is defined by a constant variable on the first line of the program. After the variables are defined, the literal function names are assigned to local variables. When that is done, they become callable methods inside the object. There are several other ways to do this within javascript, please refer to the javascript core specifiacation for details. The phpRequest maintains an internal array of Pair objects. Because javascript does not have the same array support that php does, a workaround is needed to create a key/value array. The Pair object performs this task very well. The method where the action really happens in the phpRequestExecute method. It contains the code that helps us to connect to a php server from our javascript. The javascript object that allows us to connect to another script via HTTP is the XMLHttpRequest object. It is an internal javascript object that can be used to return XML (or HTML) documents from an external source. More information about the XMLHttpRequest object can be found on the XULPlanet website. After the XMLHttpRequest object has successfully been instantiated, the url is simply created by looping over the internal array of key/value pairs. Now, you can use either GET or POST to send data to the server. I have included code for both methods. The same URL is passed, but there is one difference. When you send a POST request, you have to set the content type to be ‘application/x-www-form-urlencoded’ so the web server you are sending it to will know that you are sending a POST request. There are more tricks if you need to send larger amounts of data, but they are beyond the scope of this article. After you set the url, you must call the XMLHttpRequests send method. This is what actually sends the request to the server. Following the code, after a response from the server is received, it is stored in the XMLHttpRequest’s responseText variable and available for use. Conclusion Feel free to email questions and comments to mike _at_ tm-web dot com. More Info |
1/16/2005 @ 8:07 pm
nice site, very informative, well designed, easy to use … what can i say ? i love it…
1/18/2005 @ 5:34 am
We really liked the website .. Thank you.
1/19/2005 @ 7:43 am
%-) genuinely interested by this website