What has v11 done with Session variables?

[CALocklin]

I have some web pages that have been working for years in A5v7 through A5v10 WAS. But they won't work in v11 and I can't see an easy way to fix it.

Problem was originally noticed because of a login issue with a variable called Session.DataPath that - surprise, surprise - stores the path to the data folder. I set this variable in the index page. In v11, when I go to the Login page, that variable is still valid. However, when the user clicks the Submit button the Login page is re-read (to decide whether or not the user successfully logged in before redirecting to the appropriate page) and at that point the Session.DataPath variable is no longer valid - thus triggering a response.redirect() to the restart page.

Testing reveals that all session variables set in the index page disappear when I click the Submit button but all session variables created on the current page remain valid. WTF??

Remember - this worked perfectly for years in the earlier versions.

I've attached a slightly modified version of the web page. (Modified to protect the owner of the site only.)
WARNING: This is not your typical A5 web page. There are no web components and no "publishing" info. This is a hard coded web page that can just be copied to the website and it will work - assuming you have the tables and the variables from the Index page, of course.

I'm hoping I can find a simple solution. Otherwise I will have to completely rewrite every web page on this site using some other method than Session variables because most pages call themselves for validation before moving to the next page.

By the way, anyone who uses the A5_default_path variable in the WAS will have to modify their pages. In all earlier versions this returned the path to the current page and included a backslash on the end. In v11 the backslash was removed. (Again, WTF? I assume there was some kind of reason for this but I really appreciate the idea that I will now have to check this on every website I've created when it gets updated to v11. Especially if we weren't told about it.)

LATER:
Sorry about the attachment. I realized I hadn't uploaded it right after pressing the "Post" button. But then I got a "Website being updated" message and couldn't edit the message. Then my wife called me for dinner and that trumps everything else.

I haven't looked at the linked info yet but I'll post the attachment anyway in case anyone wants to look at it. And I'll let you know what I figure out once I've studied the additional info.

[Peter.Greulich]

Re: What has v11 done with Session variables?

There's no page attached. Session variables are no longer variables but rather objects. So don't dim you session as P. Look in the v11 release notes, i think. I saved it; here's a copy:

Xbasic - DIMMing Variables - A change has been made in how Xbasic operates when DIMMing a dot variable. If the user has not explicitly specified the scope in the DIM statement, Alpha Five will now try to see if the dot variable parent container already exists in all scopes (GLOBAL, SHARED, etc. ) and if so, it will DIM the variable in that scope rather than creating a new locally scoped variable.

It is possible that this change will break an existing application in some way. We think that chance of this breaking existing applications is extremely small, but if so, the change to your Xbasic to fix the problem will likely be very simple, as explained below.

The following example will illustrate the point.

dim global myGvarContainer.myvar1 as c = "alpha"
dim myGvarContainer.myvar2 as c = "beta"

In the above example, the user was explicit about the scope in the first statement, but not the second statement. As a result, with the previous version of Alpha Five, the following variables were created:

myGvarContainer - a pointer variable in the Global name space
myGvarContainer.myvar1 - a character variable in the Global name space
myGvarContainer - a pointer variable in the Local name space (created by the second command)
myGvarContainer.myvar2 - a character variable in the Local name space

Now, as a result of the change, the following variables are created by the above two commands:
myGvarContainer - a pointer variable in the Global name space
myGvarContainer.myvar1 - a character variable in the Global name space
myGvarContainer.myvar2 - a character variable in the Global name space

In the above example, had the second DIM statement been written as:
dim global myGvarContainer.myvar2 as c = "beta"

the the old behavior of Alpha Five and the new behavior would have been identical.

To reiterate the point here, if you look at the second DIM statement above, you see that there is no explicit scope. But since Alpha Five can find the variable container ('myGvarContainer') in the Global name space, the new variable ('myvar2') is created as a child of the existing variable in the Global namespace, rather than creating a new variable in the Local name space.

In the above example, if you want to preserve the old behavior, you can easily do so by adding this extra DIM statement (shown in red):

dim global myGvarContainer.myvar1 as c = "alpha"
dim myGvarContainer as p
dim myGvarContainer.myvar2 as c = "beta"

Now there will be two 'myGvarContainer' dot variables - one in the Global name space and one in the Local name space, and the DIM statement for 'myvar2' will create a Local variable (just as it did before this change was introduced).

Why was this change made? The reason this change was made is that users were breaking their Web applications by writing code like this

dim session.var1 as c = default ""

The reason for doing this was to ensure that a session variable existed before its value was tested. For example:

dim session.var1 as c = default ""
if session.var1 = "value1" then
'do something
end if

This would not work as the user was probably expecting because the DIM statement was actually creating a LOCAL variable called 'session' and then DIMming 'var1' as a child of the LOCAL 'session' variable.
The user was likely expecting the above DIM statement to DIM 'var1' in the Global 'session' object.
Now, as a result of the change made in this build, the above statement will DIM var1 in the Global 'session' object.
Note however, that this code pattern would still be wrong and would lead to errors:

dim session as P
dim session.var1 as c = default ""
if session.var1 = "value1" then
'do something
end if

This would create a LOCAL variable called 'session' that would mask the global 'session' object and 'var1' would have been created as child of the local 'session' variable.

Bottom Line: Do not put 'Dim session as p' in your Xbasic code in Web Applications unless (in the incredibly unlikely event) that you actually want to create a local variable of type P in the LOCAL name space.

[Steve Workings]

Re: What has v11 done with Session variables?

Cal - things are indeed changing as we move toward V12 and IIS.

You should know about this:

http://wiki.alphasoftware.com/Server...+in+Version+11

and that session variables now must always be character-type.

You'll find other threads as well about writing to and using the session folder.

[CALocklin]

Re: What has v11 done with Session variables?

There's no page attached. Session variables are no longer variables but rather objects. So don't dim you session as P. Look in the v11 release notes, i think. I saved it; here's a copy:

I have to differ with Alpha's explanation on this.

Why was this change made? The reason this change was made is that users were breaking their Web applications by writing code like this

dim session.var1 as c = default ""

(Disclaimer: I have no idea why they added the default "" in there. I know what it does; I'm just not sure why it was added. Maybe that's the catch compared to my simple DIM statement.)

First, they told us that any variable that started with "Session." would be available throughout the session.
Second, that's exactly the way it worked from the original beta version through v10 - whether DIMed or not.

The only time it doesn't work is in v11. In fact, even in v11 it works when first going to another page! It only disappears after calling the current page again.

I understand what they are saying and, logically speaking, it makes complete sense. But that's not the way it worked - not until v11. I've created websites that are working in v7 and v9 and worked on them in v8 and v10 on my desktop and they always worked even if a variable such as mine was created as:
DIM Session.DataPath as C

Now, on to the stuff Steve referenced.

[Steve Wood]

Re: What has v11 done with Session variables?

All clear as mud. At least I know I have never used "Dim session as p" in any app, so I am clear there. For the other rules, I think I have to resort to actually testing to see how it all works.

[CALocklin]

Re: What has v11 done with Session variables?

OK, this is getting even more confusing. Or maybe someone at Alpha is confused.

The stuff Peter posted says not to do this:
DIM Session.name as C ...

Then the stuff Steve referenced shows this:
session_vars.png

So apparently we're not supposed to do what we're told to do? (Good luck trying to train your kids using this method.)

[CALocklin]

Re: What has v11 done with Session variables?

OK, now that I've read the stuff Steve linked to, I'm still no further ahead. I see nothing there that will fix/cause my problem.

Also, after another look at the stuff Peter posted, I'm even more confused.

First, is the stuff Peter posted only referencing XBasic on the desktop and NOT the web app server? (It starts out with Xbasic - DIMMing Variables) If so, the description would make more sense BUT, if that's the case, why in the world did they choose to use "Session" as the pointer name? Also, what do GLOBAL variables have to do with the WAS? Isn't that replaced with a SESSION variable?

Second, that info should actually "fix" my problem. It says: (emphasis added)

dim session.var1 as c = default ""
if session.var1 = "value1" then
'do something
end if

This would not work as the user was probably expecting because the DIM statement was actually creating a LOCAL variable called 'session' and then DIMming 'var1' as a child of the LOCAL 'session' variable.
The user was likely expecting the above DIM statement to DIM 'var1' in the Global 'session' object.
Now, as a result of the change made in this build, the above statement will DIM var1 in the Global 'session' object.

So, since I've never explicitly DIMed the "session" pointer, shouldn't this "fix" make it work better? (Or, as far as I'm concerned, like it always did in the past with the web app server.)

On to more - probably hours - of testing. (I've already spent over 2 hours on this - thanks for the changes Alpha.)

[Steve Workings]

Re: What has v11 done with Session variables?

Cal, you're making this too hard.

The snippet you show from the wiki is about setting session variables from request variables. Ignore that for now because that's not what you're doing or need right now.

Instead, just simply DIM each variable in a simple form:

DIM MyVar1 as c
DIM MyVar2 as c
DIM MyVar3 as c

If you'd like, you can assign a value to the variable at the time you DIM it:

DIM MyVar4 as c = "123"

[mronck]

Re: What has v11 done with Session variables?

So apparently we're not supposed to do what we're told to do? (Good luck trying to train your kids using this method.)

I have been telling my kid for years not to do the things I did regardless of my parents telling me not to do it.

I think backwards compatibility is -enterprise wise- a great good and should not be given away that simple, but ONLY as a last resort and ONLY if you have an easy fix. The last thing is rather difficult since because the code allows several approaches programmers will produce strongly varying code solving similar problems.

The fact any software manufacturer can do this without short fusing its relationship with the customer sort of tells you something about the general Alpha customer and his products I guess.

Breaking backwards compatibility that easy has been the reason why my company could not update from version 5 upward anymore because of the misery that produced. What was allowed code-wise up to version 5 would not work anymore in version 6. However, since this particular application was sort of a living organism that changed on a daily basis, we simply could not change it to meet v6 requirements (even with a 6 person development team on it) since the part we would work on would be changed feature-wise by others the same day and so on. For large applications breaking backwards compatibility can be a showstopper for upgrading and keeping up with the Alpha product life cycle. I am quite sure in our case it did cost Alpha Software a significant amount of sales revenue since when your application can't run on newer versions it sort of defeats the reason to purchase the upgrade to begin with.

If you break backwards compatibility, you should be damn sure you got the consequences for your customers covered completely or offer your utmost to help them cope with it. That's my opinion on it.

[Steve Wood]

Re: What has v11 done with Session variables?

I agree that it is a lot of work, and a bit confusing. I've done enough conversions now that I think I will spend 2013 just doing conversions of existing application, provided willing clients surface.

I find it challenging and at the same time conversions have a "routine" quality to them where certain steps must be taken in order. An application written in V8, V9, V10 is probably due for a house-cleaning, and V11 definitely is a paradigm shift in how data is presented to the user (TabbedUI). Conversion also means from DBF to SQL because I find many developers want to go to SQL but are not sure how.

[mronck]

Re: What has v11 done with Session variables?

I always find it a bit amusing how now all must be SQL and DBF is assumed to be of "inferior quality" whilst in the past ten years or so we were all lead to believe it was almost as good as perfect. Is this what is called "marketing" ? Promote what you can actually sell, and not what your neighbor sells but you yourself can not?

SQL has a lot speaking FOR it, doubtlessly, and it is the defacto market standard for midrange use, but.... it has also things speaking against it, not in the least being the problems you encounter if you are selling off-the-shelve and pre-packaged software.

That said, I am not saying DBF is equal to or better then SQL, because I know from experience it is not. I am just amazed how those things work. Once we did not have it in Alpha, DBF was great and talking about SQL was not done. Now we do have SQL all DBF is inferior and must be exchanged for SQL. Amazing.

Given the principle that most developers will build an app to the best of his knowledge and experience, the necessary "house-cleaning" as you say Steve is most of the time not triggered by bad programming in the older version, but because of added features or changed interpretation of code, such things. The amount of work that takes can be considerably decreased if the manufacturer of the software accommodates such "house cleaning procedures" in the upgrade. Code interpretation seems to become increasingly tighter as the versions become higher. Pieces of code that you actually COULD run in v5, you could not run anymore in v6. Doubtlessly in most cases the developer would not have programmed exactly to syntax standard which then in the end, when the interpreter works tighter, delivers a problem. I have seen that in many, many cases. The problem increases in quantity once you promote your product to be something you do not have to code in at all since you obviously will then get customers who can't write good code to begin with.

I agree with you that it is challenging. Although in most cases I would have hoped the challenge would be non-existence to begin with. It is always better for you to spend your time in delivering a product that gives your customer extra functionality then him needing to pay you to "repair" functionality he already had to begin with.

[Pat Bremkamp]

Re: What has v11 done with Session variables?

I've had to bite the bullet and start changing to the new Alpha approach in old apps. I have customers who bought V11 subscriptions in order to upgrade and were very upset when told it was a major effort to upgrade.

The only customers who are happy are the new ones who bought V11 as their first Alpha product where the V11 approach could be used from the beginning.

So, for example, a small piece of an old page SetSessionVars.a5w that used to read
dim session.logo as p
session.logo.name = "MyLogo"
session.logo.high = 130
session.logo.wide = 220
session.logo.alt = "Company logo"

now reads
Session.LOGONAME = "MyLogo.jpg"
Session.LOGOHIGH = "130px"
Session.LOGOWIDE = "220px"
Session.LOGOALT = "Company logo"

Not better, not worse, just different.
Fortunately, I had this all in one place, then could use the new search to find everywhere the old ones were used. Took about 12 hours to convert the first app. Also, it was very fortunate that this was an SaaS app so I only had one generation of this software to maintain. I had tried selling copies of the app for a while and luckily, I wasn't successful. Can you imagine if I'd been trying to maintain multiple old versions? A nightmare!

Also, I think I'm one of the few who used server variables to good advantage. That was also deprecated...more hours!

And, yes, it can take weeks to convert an app from V10 dbf to V11 SQL.

I have yet to see the advantages of all this .NET integration that makes this all worth while, but then I've learned Xbasic, many of the Alpha functions, Xdialog, html, css, MySQL stored procedures and I'm only part way through JavaScript, so it'll be a while before I have time to learn that, too. I've only seen two posts on this board about .NET, both from people who already knew .NET and were trying to learn Alpha, so I don't think very many people are using it.

[Steve Wood]

Re: What has v11 done with Session variables?

Yes of course you promote what you have. That is not disingenuous, how can you promote, provide instruction for, etc. for something you don�t have?

Alpha made a commitment to add SQL and has done a pretty good job of it, except for documentation.

Did somebody say you must convert to SQL? No one said that. And I don't recall Alpha "promoting" SQL like is was mandatory. But I will say from my perspective SQL is better than DBF in every way -- including portability, power, speed, simplified routines, simplified syntax and unlimited online reference material. But it is still a jump to go from DBF to SQL; it took me several years. The reason you are hearing about SQL now is not so much because of Alpha but because a lot of DBF-die hard Developers now work exclusively (or as much as possible) with SQL. It is impossible for Alpha to write some automatic routine that would migrate an application from DBF to SQL or even from V10 to V11.

[kkfin]

Re: What has v11 done with Session variables?

If you break backwards compatibility, you should be damn sure you got the consequences for your customers covered completely or offer your utmost to help them cope with it. That's my opinion on it.

Now when Alpha is heavily integrating to .Net I hope they do finally something radical and also "clean" their xbasic to a valid logical language which would be easy to learn and easy to use.

The ongoing model in xbasic to keep everything old and and add some new is not a right direction to go anymore.
Xbasic functions and their naming system is a big mess today.

Now It is time to really break the compatibility and give us something really good and unique features in xbasic because .net integration now gives a one time opportunity to do that.

[mronck]

Re: What has v11 done with Session variables?

Yes of course you promote what you have. That is not disingenuous, how can you promote, provide instruction for, etc. for something you don’t have?

I like to promote things I believe in and stand behind. Not necessarily "what I have". There is a difference there Steve. I think it will be just THAT difference that will sign for the major changes in the world in the next Age. We need to go from "commerce" to "integrity" in increasingly more aspects of what we do.

That said, I think that the whole DBF line is nearing the end of its life cycle. SQL is available to us, but only that fact will not determine either whether it is the tool for the future. The future is never an open book. Neither is it for Alpha's management who is now staking their hopes on mobile programming. Who knows, it may be it. Or it may be not. I am quite happy I am not the one who needs to decide now for what to produce tomorrow. I try to create what my customer expects, and hopefully plus 1. The Expectation Plus One. That's what I aim for.