Skip to Content

Many of you may share my love/hate relationship with the stateful applications in BSP, or rather with writing them. Working statefully has its advantages of course, due to the nature of web applications. Variables disappear unless you pass them over to each page where you need them or else you need to put them in server side cookies. Making web applications stateful is rather handy and it’s easy to do. It’s just a matter of checking a box in the properties of your application. But before simply doing this, do look before you leap. There are some drawbacks to it (for me).
First of all developing a stateful web application is rather tedious. I don’t know how you work guys (that includes the ladies too of course), but I develop page per page. When I’ve finished a page, I test it and correct it until it does what (I think) it needs to do. If you don’t have any Letting the cat out of the bag to delete the session cookies, you need to restart the browser every time because everything is kept in the session info. Even debugging needs a restart. It’s happened to me on many an occasion that I have forgotten to clear my session and pulled out my hair – you might have noticed some bald spaces which extends my continuously growing forehead – because the application kept doing the same things erroneously despite my corrections.
Second, keeping all the variables in memory means a proper variable management, certainly if you use the same variable names in different pages. One needs to keep an eye on this when you allow people to navigate backwards and forwards between the pages. It’s just a matter of (not) clearing the variables at the appropriate time. Something you don’t need to bother keeping an eye on when your application is stateless.
Third, stateful applications don’t have a memory like an elephant – luckily there aren’t any mice in the neighbourhood either – and the variables aren’t kept for ever, even if the user keeps their browser open without touching the application. That means you need to test whether the variables are still there before you can rely on them.
Fourth and most importantly, as Tom already mentioned in his (already one year old) UPDATED! Stateful BSP Applications: New State Management Option a lot of memory is consumed when a lot of variable and tables are involved. It’s certainly a good idea to monitor things with SM04 when the application is consulted by many simultaneous users. If you don’t do this, you might end up with a server that’s stuck. The remedy is to clear things when a user has stopped the application (not only closed the browser).


Portal to peace

As Tom mentioned, there are 2 different methods to achieve this. They remain valid when the applications are called from within the portal. Outside the portal, there are some problems with it. As said many times in different web logs and articles, the cross-platform and cross-browser support is a condition sine qua non for our web applications. As you can see in Tom’s web log, Firefox/Mozilla/Netscape support is rather problematic. That’s why we’ve tried, together with the guys from OSS , to come to a solution that’ll work fine with those browsers.
The result of this can be downloaded at this location. There isn’t that much difference with the previous versions though. It works with more convenient iframes and has special tests for Netscape 7.0X. In order to let that work you need to copy the session_default_frame.htm from the “system” application. I won’t explain the code because that’s already been done perfectly by Tom and Brian.


Pop up goes the Weasel

Wait a minute, doesn’t this code include popups and wasn’t that one of the problems Tom wanted to get rid of? Indeed, you’re 100% right. In our situation it isn’t that problematic, since we need popups to display or repertorium – despite the fact that I hated Latin in my school days I seem to use it quite often – tables. Popup blockers are rather useless these days anyway since the professional advertisers use (more annoying) DHTML techniques in order to palm off their commercial messages on the users anyway. But the popup blockers are still widely used, so one needs to detect whether that kind of software is operational for your domain. That’s easily done by opening a window and seeing whether it fails or not. When it fails, the user needs to be notified to switch off the blocker for your domain. Don’t forget to close the window. All this happens within the twinkling of the eye, thus the user doesn’t really notice it. The whole code can be found in my earlier Popup the jam .


The unfortunate cookie

My first The unfortunate cookie on SDN dealt with the fact that server cookies were affected by browser settings. If you configured your browser not to allow client cookies to be set, server cookies weren’t set either. That was clearly an error which should have been fixed via an SP by now. If you don’t trust this, or if you want to set client cookies for some reason, you need to be sure that the user didn’t disable it so you have to test it. Again, no rocket science if you have a look at this code.

var cookieEnabled=(navigator.cookieEnabled)? true : false
//if not IE4+ nor NS6+
if (typeof navigator.cookieEnabled=="undefined" && !cookieEnabled){
cookieEnabled=(document.cookie=="testcookie")? true : false
document.cookie="" //erase dummy cookie
if (cookieEnabled==false) //if cookies are disabled on client's browser
alert(' Pls allow cookies on your browser ');
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply