[thelist] Application Vars in ASP

[Chris Marsh]

> >What are the implications of this many Application Vars?
> >Would I be better off changing all the app vars to normal vars and
> >stick them in an include file on every page?
>
> Each time a user connects to the site an Application instance
> object is created and populated with everything added in the

I was under the impression that this was what occurred with a member of
the Session object's Items collection. The Application object AFAIK can
be used to store values that need to be constant across all users of the
application thus being a much more efficient means of handling values
with application scope due to low memory usage.

> global.asa. I personally wouldn't want a massive object
> floating around my application, but hey, there's always
> reasons people may want exactly that.
>
> >Is it worth putting functions in the global.asa?
> >what are the implications of this?
>
> One thing it would do is eliminate include clutter. A major
> problem with includes (with VBScript anyway) is namespace
> collisions, where you have a variable declared in two
> separate scripts at the same level (i.e. global within the
> script). Once you tie them together with includes, the system
> dies a horrible gut-wrenching death because VBScript can't
> deal with re-declaring variables. This applies to functions,
> subs, classes, etc. Basically anything you can "name". If
> it's not in a function or a sub or a class (or a property
> within a class), it's global.

This is one of the reasons that I attempt to take a much more OO
approach to ASP programming. Using classes allows a lot more flexibility
with naming, and allows me to create a much more structured application.
Of course one mustn't get too excited about it, as VBScript isn't truly
object-oriented. In addition you will take a slight performance hit,
although I can usually bear this for the increased efficiency of
application development and maintenance.

Regards

Chris Marsh