/   Site Map  /   About Us  /  General Products  /  MV Products  /  Outsourcing   / Home page   /

Remote Scripting and PixieWeb

PixieWeb

DHTML, dynamic creation on the fly of page elements With our PixieWeb tool-kit, Web application pages are able to have an ongoing conversation with PICK Programs. It is possible for that initial Web page to be a standard blank slate, like a terminal, with the server able to rewrite part or all of it (using PixieWeb field-by-field keywords “IREPLACE”, “INSERT”). The issues around control of user "freedom of navigation" are solved completely. Here the entire application consists of only one template page and the user is locked down to that page. Leaving it or closing it cues the application to logoff and disconnect. PixieWeb is based on Microsoft’s “Remote Scripting” technology. Quoting here and below from http://msdn.microsoft.com/scripting: “With remote scripting, developers can now create seamless, interactive Web applications in which the browser can call scripts on the server without reloading the Web page. Prior to remote scripting, developers would have to require the user to reload the calling page, often several times, to interact with the server. This created a slower, disjointed, user experience and inefficient use of the server.” Internet Explorer 5 and above have a suitable transmission method built-in, the “XML Download Behaviour”. This is fast, and makes for much simpler application installation on the Web server. The application only depends on the basic features of IE without any issues around Java or any other installation optional extras. The “XML Download Behaviour” is our preferred method, but we do supply a slightly slower but more flexible one. Our Web application templates are easily changed to the “Array of IFRAMEs” method. The use of separate invisible windows (“frames”) to take the hit of being erased at each conversation step is an old idea. Its main problem is that it fails to manage requests in queues, as in a user working fast from field-to-field can cause new transmissions to destroy earlier ones in progress. We have solved that problem by using three IFRAMEs which rotate in turn at being the transmission device. In theory, the array of IFRAMEs demands more processing power from the client. In practice, most recent machines, can run it almost as fast as the XML Download Behaviour. Apart from supporting IE4, the IFRAME object is now available in Netscape 6 as we have successfully translated our client-side BASIC VBscript template page into JavaScript to support Netscape 6. Executing Server Script Remotely Sophisticated Web applications involve both client and server script. Client script is often used to program the user interface for an application - for example, to change Web page text dynamically, respond to user actions such as button clicks, and perform such client-oriented tasks as validation. Client script executes locally in the browser, which provides the user with a lively and responsive interface. Server script, in contrast, is used to program an application's back end. This often involves accessing a database or performing middle-tier business logic. Server script is also used to create applications with broad reach: applications that might be accessed by many different types of browsers, each with different capabilities. But client and server script are mutually exclusive. When a page is first requested, the server can run server script, and then pass the page to the browser, which can then run client script. However, if server script on the page must be run again, the page must be submitted back to the server, which effectively restarts the page. Maintaining the state of controls in the page and the values in scripts can involve complex scripting to pass information back and forth between the browser and server. In addition, the roundtrip between client and server involves overhead that can slow an application. An alternative is remote scripting. Remote scripting allows you to work in client script, but call methods (function or subroutines) in an ASP page. In effect, you can call server scripts as if they were local routines, but they run on the server, with full access to the capabilities of the server. Because you never leave the current page to call the server script, the state of the page is maintained. You can use remote scripting for such tasks as: 1) Data lookup and data validation on the server while the user continues to interact with a data-entry form. 2) Updating information in the page from the server without the need to refresh the screen. How Remote Scripting Works Remote scripting is implemented as a library of functions that you call from client script when you want to run a server method. When you call a server method, the request is routed to a proxy process that runs asynchronously in the browser (in the current implementation, the proxy is implemented as a Java applet.) The proxy process sends a request to the server for the ASP page containing the method you have called. The server loads the ASP page, and a special routine on the ASP page dispatches your requests to the correct function. If the method returns a value, it is sent back to the proxy process, which packages it as an object - a call object - containing properties for the return value and other useful information. When you make a call in client script to a server method, you can choose to do so in two ways: 1) Synchronously Your script calls the remote procedure and waits for it to return. This is useful if you need the results of the remote procedure before you proceed. 2) Asynchronously Your script makes the call to a remote script, and then continues processing. The page remains available for users to work with. Asynchronous calls are useful when a call might take a long time.  Pixieware connects you easier, faster and more reliably to MultiValue data.

Email: sales@pixieware.com

/   Site Map  /   About Us  /  General Products  /  MV Products  /  Outsourcing   / Home page   /