As web sites become more and more like traditional applications, the call-response-reload model used in HTTP transactions becomes increasingly cumbersome. Instead of delivering a single dynamic page, the DHTML or JavaScript developer must create a series of separate pages. The flow of the application is interrupted by page reloads whenever the client communicates with the server. Remote scripting provides a solution to this problem, easing development of complex JavaScript applications, and providing a better experience for the end user.
What is Remote Scripting?
Remote Scripting is the process by which a client-side application running in the browser and a server-side application can exchange data without reloading the page. Remote scripting allows you to create complex DHTML interfaces which interact seamlessly with your server.
If you're not clear on exactly what this means, think of the ever-present JavaScript image swap (you've coded one of those, haven't you?). In an image swap, your client-side code requests new data from the server to be displayed on the web page; in this case the request made to the server is for a new image with which you wish to replace an existing image. But what if you could ask the server for something other than an image? What if you could request a block of text? And what if your request could be more than a simple call for data? What if you could submit form data back to the server, have the server process that data and respond with an appropriate message? Of course, all of these things are already possible by relying on page reloads, but remote scripting allows complex interaction with the server that appears as seamless to the user as a simple image swap.
Remote scripting is a form of RPC (Remote Procedure Call), which is a general term used to describe the exchange of data between remote computer systems. Remote scripting opens up a great number of opportunities for the developer. Imagine a news article that can load side bars and graphical information related to the article directly into the web page when the site's visitors request it. Imagine a gallery of photo thumbnails that turn into full-sized images when clicked. Imagine a full-featured, browser-based content management system interface that allows a site administrator to edit web site copy in situ. The possibilities are limited only by the creativity of the developer.
Setting up Remote Scripting
As I'm sure you've gathered, remote scripting is a client/server technology that relies on two distinct components: the server, which is your web server, and the client, which is the JavaScript application in your web page. In remote scripting, you'll be making an RPC from your JavaScript application to your server. You'll need to be versed in both client and server web technologies to get started with remote scripting.
The client-side component is a part of the web page that you want to enable with remote scripting capabilities. It needs to be able to make a call back to the server, usually done via HTTP, and to then be able to receive and deal with the server response, if any. The server component must be ready to receive requests from the client, process the request, and then respond, returning data to the client if needed. The server component can be a script served up by your web server, such as a .php, .asp, or .cgi file, or it can be a dedicated software package that handles only RPC calls, or it can even be a simple database comprised of static files.
As you can see, the requirements for each of these components will vary greatly depending on how you choose to implement your remote scripting system.
Remote Scripting Technology Options
Remote scripting is actually a fairly broad term, and does not necessarily imply the use of any particular technology. Several remote scripting options are available to the web developer:
Java Applet/ActiveX control/Flash By embedding an ActiveX component, a Java applet, or a Flash movie into your web page, all of which are capable of making HTTP requests and interacting with your client-side JavaScript code, you can implement the client component of a remote scripting system. Not all browsers support the technology (called LiveConnect) that allows for interaction between JavaScript and such objects; most notably, IE5 Mac does not support it at all, and NS6 (on all platforms) has such splotchy support it cannot really be called support at all. In addition to those problems, using an embedded object for remote scripting requires the end-user to install additional proprietary software. ActiveX does not work on the Macintosh platform, and Java can cause some difficulties with some versions of Internet Explorer. On the upside, Java and ActiveX can create socket connections with the server, which allows the server to interact with your application even when communication is not initiated by the client component. Unless you're developing in an environment where browser homogeneity can be assumed, these technologies may not be a good choice for remote scripting.
XML-RPC is in many ways the superior choice for remote scripting. It uses XML for encapsulating data, HTTP for its transport mechanism, and can be implemented in a wide variety of platform and software environments. XML-RPS is an open, standards-based technology that is quickly becoming the de-facto method for RPC of all kinds. The down side is that it takes a bit more know-how and work to get it up and running, requiring the installation of XML-RPC libraries on your server and in your client-side code. It also does not work with IE5 on the Macintosh.
Simple HTTP via a hidden IFRAME Using an IFRAME in conjunction with a script on your web server or a database of static HTML files, is by far the easiest of the remote scripting options available. The IFRAME has been part of the HTML specification since version 4 and is supported in nearly all modern browsers. On the server, you can use your scripting language of choice to process page requests made to the IFRAME. In the remainder of this article you'll see how to implement these components.
Using an IFRAME for Remote Scripting
Enough already with the talk! Let's get to the code. I'm going to show you everything you need to know to set up a remote scripting system with an IFRAME. I'll start with the basic set up, and describe some common browser problems and their solutions.
For starters, you'll need two web pages. The first should be called client.html (or some variation thereof, depending on the example). It will be the main working document and will contain nearly all of the scripts. The client.html will be making remote scripting calls using an IFRAME embedded in the document's HTML. The second page will be server.html. In a live server environment, you'd call it server.php, or server.asp, or whatever extension fits your server platform, but in this example we're not using a dynamic server component, so an .html extension is fine.
The client.html file will make RPC calls by passing arguments to server.html in the query string. The server.html will process the RPC, and write out a very simple page which contains script calls back to client.html. This will be clearer after we look at a simple example.
In client.html enter the following:
make RPC call
As you can see, in it's simplest form IFRAME remote scripting simply points the TARGET attribute of a link to a hidden IFRAME. You can hide an IFRAME by setting its WIDTH, HEIGHT, and BORDER properties to 0px. Don't use display:none, because NS6 ignores IFRAMEs when the display property is set to none. If you were using the above code with display:none set for the IFRAME, the contents of server.html would load into the main client.html document, not into the IFRAME.
In server.html use the following HTML:
The handleResponse() function is found in our client.html page, and we simply use the parent property of the IFRAME document's window object to call it. See it in action here. Of course you notice that in this example we are not actually processing anything on the server. If you want, on your server go ahead and change your server page code to something like this (I'm using ASP as an example server scripting language):
And change the handleResponse() function in client.html to something like this:
You should now get an alert message containing information returned from your server, the results of your first remote procedure call!
Should you want to pass data to server.html, you can either embed it in the query string of the URL specified in your link, or, to allow user interaction, use a form instead of a link, like so:
Just like the link, you specify the IFRAME as the target of your form, use server.html to process the form data on the server, and send any data back with the handleResponse() method. More on working with forms later.
Problems and Solutions
You may have already realized that there are some serious problems with this simplest of remote scripting scenarios. Perhaps most seriously, this method renders the "back" and "reload" buttons in most browsers useless. Because the loading of server.html in the IFRAME is added to the browsers history object, hitting the reload button after you've loaded server.html, for instance, reloads server.html in the IFRAME instead of reloading client.html as would be expected.
NOTE: You may or not experience this problem, depending on a combination of factors including your browser version, server platform, HTTP headers, and browser settings. Trust me, if you simply target a link at an IFRAME, some users will have problems with their reload and back buttons.
A new function called callToServer() handles this problem by using the replace() method of the IFRAME document's document object. In addition, instead of creating an IFRAME element in the HTML, I'll let callToServer() create the IFRAME through the wonders of the DOM. Doing so alleviates all the reload and back button problems, and keeps the mark up free from unneeded tags.
Sadly, referencing the IFRAME's document object is no simple task, since IE5, IE5.5, IE6, and NS6 all provide different ways to access it. IE5, both on the Mac and PC, provides the simplest method: IFRAMEs in this browser show up in the document.frames array and have a document property. In IE5.5, IE6 and NS6, you can retrieve the IFRAME element object with document.getElementByID(), then, in NS6, use the object's contentDocument property, and in IE 5.5+, use the document property of the IFRAME object's contentWindow property. That's quite a mouthful, isn't it? Thankfully, it's quite a bit simpler in the actual code:
var IFrameObj; // our IFrame object
function callToServer() {
if (!document.createElement) {return true};
var IFrameDoc;
var URL = 'server.html';
if (!IFrameObj && document.createElement) {
// create the IFrame and assign a reference to the
// object to our global variable IFrameObj.
// this will only happen the first time
// callToServer() is called
try {
var tempIFrame=document.createElement('iframe');
tempIFrame.setAttribute('id','RSIFrame');
tempIFrame.style.border='0px';
tempIFrame.style.width='0px';
tempIFrame.style.height='0px';
IFrameObj = document.body.appendChild(tempIFrame);
if (document.frames) {
// this is for IE5 Mac, because it will only
// allow access to the document object
// of the IFrame if we access it through
// the document.frames array
IFrameObj = document.frames['RSIFrame'];
}
} catch(exception) {
// This is for IE5 PC, which does not allow dynamic creation
// and manipulation of an iframe object. Instead, we'll fake
// it up by creating our own objects.
iframeHTML='\
courtsy: apple.com
No comments:
Post a Comment