Web App refresh (URLs)

On a CGI web app, when the user presses the refresh button, the web app takes the user to the first window in the app, in my case the login page. Is there a way to avoid this?
What is best practice in building web apps and managing URLs? Even though Xojo web apps only shows 1 URL, it is not based on URLs.
I hope the answer has nothing to do with WebApplication.HandleSpecialURL(), this would mean we have to have a case scenario for each page we build.

Refreshing the page starts a new session. You ought to be able to use a Cookie or perhaps the HashTag to save and restore the user’s position in your app.

Also, take a look at the EEWeb example. We intercept users leaving the app by setting the ConfirmMessage.

Thanks, will check both suggestions

’ Stop user exiting browser
me.ConfirmMessage=“Are you sure you want to exit this site?”
Put this in session.open to stop people using back or refresh in the browser.

Basic question but here goes: if I have a user logged in to my xojo web app and they then refresh (reload) then the session is blown away and I have no way of knowing if the refreshed ‘user’ is the same as my logged in user ?

You need to know about cookies, hash tags and state machines.

Thanks James,

I am more or less across thise things. The link doesn’t resolve btw.

So one has to code ones own persistence mechanism as none are included in xojo. Accurate statement ?


James link works here…

What do you want to achieve ?

Hi Michel,

Was simply wondering why there is no built in session persistance mechanism. Xojo Web is for building web apps so this is needed.

Wonder what ithers do/use ?


Greg provided a simple way to prevent users from refreshing prematurely.

Xojo Web is pretty unassuming, but the mechanism behind sessions is far from being that simple, and making it persistent involves more than a simple switch. If I am not mistaken, there is some amount of persistence when mobile clients are concerned. Greg would be able to tell.

You got to understand that web apps are inherently different from web pages. The very notion of session means all along the user visit, the app has to know at every moment who the user is. A web page has no notion of session. The server, most often Apache, simply serves whatever page is at the given URL. And then it forgets. So when you hit refresh, it simply serves again the same page. But there is no notion of persistence at all. If you entered something in the page, it is gone.

Big web apps, such as bank apps, all have the notion of session, but a lot of them simply cannot be navigated with the forward and back arrow, or even refresh.

[quote=442756:@Stephen Pardoe]Hi Michel,

Was simply wondering why there is no built in session persistance mechanism. Xojo Web is for building web apps so this is needed.

Wonder what ithers do/use ?


I think you are missing some of the finer points here. A XOJO web application is a SPA and like all such applications, it is in fact two applications - server and a client. The server has session, but the client does not. This is how it is for all SPA applications regardless of which development language you use.

You need to provide the mechanism to save client state, because it is application specific. And you do this in XOJO the same way as in any other development environment, with hashtags, cookies and a state machine of some kind or other.

In the case of say just displaying a customer info page for instance you can probably get away just using a hashtag plus a customer ID on the URL. But as Michael already pointed out, in something like banking applications, which is what I do, you need to do a lot more to ensure a client can get back to a given state.

Preventing people from refreshing the page BTW, does not work in the real world. People expect to be able to bookmark your app at any given point and go back there later. They expect to be able to work on your app, take a lunch break and continue where they left off an hour later without a loss of data etc…

No matter what tools you use building business applications as opposed to websites is a very challenging task.