Private module-level variables

[ESquared]

I know that in an active server page, all includes are processed as if they were part of the original file. There are situations, though, where I would like to have the functionality of Private module-level variables. That is, in one .asp file (which I might include from somewhere else) I need a variable that is global to just that file, but not to the rest of the application, in order to retain a state. Is there a way to do this?

Do I code things in weird ways to always pass a variable in, and create my lookup values using the same function which returns them? For example, I have a "module" which reads various database connection strings from a file into an array (or a collection, I haven't decided yet). There will be another function which returns a connection object to the desired database. So when the .asp file is first included, I want it to read the connection strings once, then after that if the function is called, hand the selected one out.

So how do I retain the array of connection strings without a global variable that might collide with the name of another variable I wish to use somewhere else?

Is the answer to use classes? There's still a global variable to hold the instance of the class.

 

[damber]

First, you need to think of the page with all of it's includes as a single object instance - like a class instantiation.. all variables inside that Page (the includes are considered part of the page) acts similarly to those of a class - i.e. you cannot hide a bog standard variable from another within a normal class as they both point to the same memory segment within the namespace of the class / page.

With that in mind, you can then extend that idea with the inclusion of a VBScript Class - which conceptually extends the namespace of the page e.g. Page.Class.Property etc...

So, if you really need to use the same variable names in different includes, then you can use class objects within the includes. At some point you need to instantiate them, but at the worst you can just use the page name as the class name and variable name, therefore using it more like a namespace than anything else. Class Objects also keep their own state until you destroy them explicitly or the page closes and they are destroyed implicitly. However for that purpose I don't see how changing the variable name wouldn't be easier.........?

I'm still not sure what it is that's the issue for you though... is it a problem with state management.. if so, why do you need a file to have it's own state ? A Request has it's own logical state, and therefore the page and it's contents.. but why do you need an include file to have it's own state ... what state would you maintain ? Classes maintain state, so maybe this is what your referring to ?

Or is it just naming conflicts ? If so, in most cases, this just requires more detailed control of the design of the pages. If absolutely necessary you can use a class as a type of namespace feature. It is most likely that you can simply redesign things to be more considerate of the page's variables and naming conventions - because if a variable is globally accessed for the entire page, then it needs to be globally accessible for the entire page ! In which case you need to fix the naming conventions or use classes as namespace holders (if you really think that's what you need)

Or are you having issues with your connectionstrings ? Simply keep a global list in an application variable(s) and then hold a 'current connection string' app var or session var that determines which connection string to use. (you can do this in global.asa once for the application startup and you can determine the "current" setting at app startup to decide whether you are on a dev server or production server etc).
That way, you only read the file once, store the strings in memory and dynamically access them without needing to remember to include a file on every page.

I'm not sure if that answers your question(s) as I'm not sure I fully understand which of the things you've talked about is an issue.

Hopefully that helps....!



A smile is worth a thousand kind words. So smile, it's easy!

 

[ESquared]

damber, thanks for replying.

My thoughts were already running along the lines of what you've said here about using the filename as a kind of namespace. And in fact I've already built the code to put my connection strings into an application variable in Application_OnStart.

One thing that I've noticed is that when you use Execute to run some ASP code contained in a string or file, the variables declared in that code have a scope of only the execute statement, sort of like dynamic SQL's scope.

 

[damber]

Yes, Server.Execute uses it's own memory space during execution so it effectively gives you private variables - so they are not accessible from the calling script (at all).

Execute() as a function (without the server bit) will execute the string input as if it was part of the current page execution.. e.g.

Execute("function fRun(sPrintMe) " _ 
	 & vbcrlf & " response.Write(sPrintMe) " _ 
	 & vbcrlf &  "end function" _ 
	 & vbcrlf &  "sToPrint = ""hello""" _ 
	 )

fRun(sToPrint)

would print hello just as if the function had been written normally.

This means that you could theoretically use FSO to get script/code from an asp file and execute it in the context of the current page.

But that just seems a bit messy and inefficient, so I would avoid this unless it was the only way to go.

Hope that helps,


A smile is worth a thousand kind words. So smile, it's easy!