Hi,
My problem: I have a WebSpeed app where a request from one page (page A) to another page (page B) takes lots of time (normally 10-40 seconds sometimes longer). This is because of communication with an external system so I have no real option of speeding it up. While this page is loading the browser displays a white blank page and this isn't very good. What I would like to do is to display a page while processing that says: "Please stand by your request is being processed" or similar.
Facts: OE 10.1 A, Apache Webserver 1.3.x, Sun Solaris 10.
Now I have 3 ideas:
1) Create a middle page, post from page A to this middle page. Place a META HTTP-EQUIV="REFRESH" tag in this page and direct it to page B. It will cause the browser to display the middle page while loading page B. The problem is that it breaks the default behavior of the browser making the Back button from page B behaving in a wait you wouldnt expect.
2) This one is a bit trickier. It would require one or two new tables in the database. One storing request data and one storing request responses. On loading page "B" I create a record with the request data then I spawn a background process that starts working with this request. The background process writes the response from the external service either in the second table (or possibly in a file on disk). Meanwhile page "B" reloads every other second checking the post to see if the request is done. If it is so it reads data from the second table and displays it. Otherwise it just shows the waiting message again. This feels like a more professional solution but it would require quite much work.
3) This solution is a bit more vague. It's basically solution number 2 but instead of creating a record in a request table page B does an async appserver call and thus starts the request. Then it somehow checks back with the appserver every other second to see if it is done and then reads the response either from a table or from a disk on file. Since I haven't worked with async appserver calls I'm not 100% sure it would work but it's a thought anway.
Does anyone have any comments to this or perhaps other ideas? All input is greatly appreciated. I really think there should be an easier way of doing it without breaking any usability rules (as in solution number 1).
Best regards
Jens Dahlin
Airtours
jens@airtours.se
AJAX. That way your data request can be in the background.
AJAX might be a solution but I don't think it will be easier to implement compared to rewriting the app using a server based background process. And if there isn't any time to spare I would prefer not using AJAX.
You don't have to use a full AJAX-framework, you can use the JavaScript XMLHttpRequest object (http://en.wikipedia.org/wiki/XMLHttpRequest). There are lots of script samples around you can use when you search for it. The good thing about this object:
- you will get a callback when the request is finished
- you can cancel the request
Combine it with an animated GIF for the "wait while processing"-message and the solution is complete. You can even add a timer and change the GIF when you want to spice up the solution...
I think it's a very bad design choice when you start polling the web-server every second. Think about this scenario with 10 or 100 users: it's a lot of network traffic for some progress indicator.
If you only need a single implementation of this, then you could use a hidden frame. When the main application window posts to the hidden frame you can display an animated image or something similar to give the appearance that things are happening. When the frame finishes loading, then you the onLoad of the body to run some javascript that updates the main page.
This method scales as well as ajax, but is simpler to program (you don't have to deal with xml on either side). The upside of ajax is that if you need to use it in a lot of places its easier to standardize on a single methodology.
Method 3 won't work. The problem with this approach is that the asynchronous request is spawned by a particular webspeed agent. Since webspeed uses a round-robin approach for each web request, there is no way to predict which webspeed agent is going to handle the request. If you have 5 agents running and agent 3 makes the request, then 4 out of five requests will either respond to someone else's request for the same data or simple return an error. By the time you're refresh gets around to hitting the right webspeed agent, it could be that the agent has been trimmed by the broker.
You're likely to tear your hair out trying to get something like this to work.
The words "Webspeed" and "Asynchronous Appserver" don't mix well.