Wednesday, October 14, 2009

How to keep track of session variables in a web app

Almost every web application requires multiple session variables that need to be DIM'd and set to a value. A typical example might be setting "session.clientname" to the logged in user's first and last name, for convenient use when you want to display their name on a web page. Other variables are more important, like the logged-in users personal ID (commonly called the ULINK in Alpha web apps) so you can filter out just their records, and perhaps a Company_ID in a multi-tier application where you need to know their Company affiliation while logged in.

I have a standards set of session variables that go into each web app, ones I use all the time. Those are easy to keep track of, I know them by heart. But every web app also needs a host of session variables that are unique to this application. I devised the following method both to keep track of these unique session variable names and also to make it easier for me to add them as I build the application.

The normal process for adding a session variable is to add some Xbasic code either right where you first need the variable, or in a header type file that is included on ALL web pages. The later method ensures the variable is repopulated every time any page is refreshed. There is a reason you might want this, but I won't go into it right here.

Being data-driven to a fault, I now keep all of these extra session variables in a table, and use Xbasic to extract the information from that table in order to DIM and populate the value. I include a convenient checkbox to indicate if the variable is 'protected' or normal. "Protected session variable" is a term unique to Alpha Five.

Hint: click on the images below to get a larger view. If you cannot read all of the text, click this link to get it in a text file. You can also click on the image to get a larger view.

Here is the table structure:



And here is some representitive data for the table. Note that the 'expression' is normal Xbasic, exactly what you might enter directly on the A5W page to populate your variable. If you check 'Protected' it will automatically insert the text required to make the variable protected. If you include a 'Footer_ID' the current value for this variable will appear in the footer of your web application, which is good for debug purposes while you are testing the application online.


Here is the Xbasic on an A5W page I have named header_setvar.a5w. Note that there is NO HTML on this page, just the requried Xbasic. Note that I use 'evaluate_template()' to extract the information from the table. If I don't include that, the results just appear as normal text in the browser, not fired as Xbasic.

Here is the Xbasic on the individual pages to include this header_setvar.a5w. Typically this would go at the top of every A5W page. In reality, I do not place this header_setvar.a5w on individual pages, I include it another page named header_head.a5w, and that page is included on all other pages. But that is personal preference. Just the line that starts with A5W_Include is imporant here.



Here is the Xbasic that goes in the Footer.A5W page to be able to display the values for each of my session variables while testing the application. In the image below, I included some extra code that shows how I can toggle this 'debug' information off and on while online; that is the initial IF-ENDIF statement. The lines you care about to show the session variables are the two lines starting with dta3.



And here is what the footer actually looks like. It may appear to be nonsense to you, but it tells me exactly what is going on in terms of who is logged in and how that has affected the session variables. This is invaluable data while testing. When I go live, I toggle this debug information off.


2 comments:

Chris said...

I have done something like this in a programmed excel worksheet to keep things straight, avoid naming errors and prevent writing the same lines of code over and over, especially for dialogs when there is a lot of table fields that will be populated. But then have to copy paste everything.

This was really informative.

Roderick said...

Is this built into AlphaToGo? That would be awesome.