Stateful Internet Applications (ajax experts required)

[eluser]obiron2[/eluser]
Hi guys, long time no post.

I am in the process of reviewing some IT systems for our company (retail EPOS) and one of them was entirely internet browser based (running in kiosk mode so no access to history)

One of the things that really impressed me was that if the browser crashed or the machine was turned off, the appliation recovered from the state it was in.

For example. You start a new transactions and enter an item code and the system returns the price - (easy: just an ajax query to the database and inject a new div into the DOM). If the browser crashed and you recover, the till shows the transaction with the item entered.

Whenever I have written ajax apps, the browser history only remembers the contents of the page when it was first served up and not any changes you have made with javascript.

How would you go about the design concept for this 'stateful' application. Would you need to write the order object data back with each ajax call, or just call an object method for each action and re-serve the whole of the object details to the browser with each ajax call. I am pretty sure they are not storing anything other than a session cookie locally, but I am interested to know whether you would try to hold the object data browser side or if not how you would keep the object server side and would you use generic controllers to intercept and interpret the ajax calls as the user changes the object in the browser (add, remove lines, select payment method etc..)

Also, they managed to print to a receipt printer directly from the browser application without windows popping up the print dialog box. Any idea how you would do this?

Thanks

Obiron

[eluser]wiredesignz[/eluser]
Sounds more like a 3 tier desktop application using a browser GUI than a true web application.

[eluser]obiron2[/eluser]
Nope, It was definately running in IE and was all hosted server-side.

If your machine fails, you install a new one and it will pick up where you left off based on the IP address, if not recognised will prompt you for the location and till number (stored in the cookie) and pick up where the old machine left off.

damn clever if you ask me

Obiron

[eluser]gon[/eluser]
If you set a cookie in the browser, you should be able to store the app state at the server. This way you can recover from a browser crash.

The state should be saved when you make any change that modifies what the user see or any other aspect of the app. You should design a codification that allows the server to store at the DB any screen configuration that the user has at the browser.

Then, if you load the page, you could render it at the browser at one time, as if the user had been doing changes starting from other app state.

The difficult part is that you must be able to render both at client and server side, depending on if the user is doing changes, (client side rendering of new content), or the user loads the page the first time (server side rendering).

Widgets are used just to do this.


For printing, you could try a hidden iframe, in which you load the content to be printed, and a script that sends a print command when loading has finished.

[eluser]wiredesignz[/eluser]
Cookies are not the solution here, especially if machines can be swapped out.

I would say again that this is probably not a true web application, more likely an application server backend, using a web server interface. Interactions would be equivalent to a desktop app, the state is maintained on the server and easily resumed after interuption.

[eluser]Randy Casburn[/eluser]
@obiron2,

You should look into some of the very cool stuff going on with server-side JS. Go to the Aptana web site and look at Jaxer. You may find a new world is available to you in terms of client/server interaction. Statefulness being on small part of the equation.

Randy

[eluser]Rick Jolly[/eluser]
Server-side javascript == classic asp using JScript. Ralf. Or am I wrong?

[eluser]obiron2[/eluser]
what benefit do i get from coding SSJS rather than using MVC in PHP?

As far as I can see, it simply allows me to generate the initial html and the DOM by referencing DOM components rather than outputting HTML.

I would still need to use CSJS to run AJAX

I am a dabbler, rather than a coder. I get the basics of OOP but the clever stuff still eludes me

Obiron

[eluser]Randy Casburn[/eluser]
From your earlier post:

For example. You start a new transactions and enter an item code and the system returns the price - (easy: just an ajax query to the database and inject a new div into the DOM). If the browser crashed and you recover, the till shows the transaction with the item entered.

Whenever I have written ajax apps, the browser history only remembers the contents of the page when it was first served up and not any changes you have made with javascript.

Suppose all the client side STATE INFORMATION as described above was now magically/seamlessly stored on the server side simply by adding one phrase to your code: "runat:both". In other words, all of your DOM manipulation can be accomplished stored in real time on the server and the client together, or just client (traditionally), or just server.

That's pretty much it I think.

[eluser]obiron2[/eluser]
so by storing a session ID in the cookie and on the server, I could actually store the HTML output that the user should be seeing in the sessions table... ( or build it from the data in the databse about where we are in the order process)

at any point in the process I can refesh the entire browser to ensure that what is being shown is correct?

or have I missed the point.