: 1) If the Name of my CFAPPLICATION is the same for each business,
: then I risk users overwriting each other's variables.
Only if you are storing data there that shouldn't be stored there. The
application scope is intended for use for storing variables that are common
to every instance of an application. Storing data there in the way you
described is basically a misuse of the application scope.
: 2) If I use a unique, dynamic Name for each CFAPPLICATION when
: a person enters the site, then I can use Application Scope variables
: without them being overwritten with 2 or more users on the site
: concurrently?
Yes, although I think what was suggested is that you create a different
application name not for each request or user but rather for each different
set of data, ie for each domain.
: Does having a unique Name for the CFAPPLICATION affect the names
: of Application variables behind the scenes? Or do the two have
: anything to do with each other?
Nope. You define the name of the application once in the cfapplication tag.
This is simply to allow you to differentiate between applications. After
that, you use the standard application.variable calls and they should work
just fine.
That is, application "bob" and application "sam" can both have application
variables named "var", but application.var called in the bob application
will never reference the application.var in the sam application and vice
versa.
: 3) Even if statement 2 is true, change all application variables
: to request
: variables
: for use throughout the site?
I would, simply to avoid locking issues. Remember, locking slows your
application down.
: Concerning Session, Application, and Request scope variables:
:
: 1) Application variable access are not specific to a particular user's
: session on the site?
Correct. They are specific to (surprise!) an application.
: And, therefore, a specific variable *can* be overwritten by different
: users within other users' sessions?
Yes. So don't do that. :-)
: 2) Session and Request variables are specific to a particular user's
: session on the site?
Yes and no. Session variables are specific to a session (they are
referenced by checking cookies or url tokens and persist until they are
deleted or time out).
Request variables are specific to a single page request. They persist from
creation until the page has finished processing and is served. Then they
dissapear. They differ from variable scoped variables (how's that for
redundancy?) AFAIK in that request scoped variables are accessible from
custom tags.
: And, therefore, a specific Session or Request variable *cannot* be
: overwritten by different users within other users' sessions?
Correct.
: Concerning Locking:
:
: 1) Application variable need to be locked.
Yup. Since multiple requests can read/write, you have to make sure that no
one is reading an incomplete write, or trying to write then read while
another request is trying to change the values, etc.
: 2) Request variables do not.
Never have to lock these as they are specific to a request and therefore
aren't shared.
: 3) What about Session variables?
Always. If there are two simultaneous requests from a single session, you
see the same problems as with application variables if you don't lock them.
: I've done some reading on the scope variables, but haven't found the
: explanation
: of the kinds of aspects we're discussing. (Perhaps I just haven't looked
: hard enough)
: If you can tell me where to find a good explanation of these things, then
: perhaps
: I wouldn't have to have you spoon feed me so much! I am rereading the
: documentation
: on scope variables, now that I need deeper understanding.
: Perhaps there are
: some
: other good articles/resources for understanding you know of?
I got most of this from the CF5 Certification study guide. I had some help
understanding client variables from the list.
: I like your idea below...it puts some framework behind what I'm trying to
: do.
:
: When the Request variables are setup, I won't define every piece of
: information
: for the site at that time, in order to keep things moving. I figured I'd
: wait to
: define, for instance the BusinessAddress, with a query with the BusinessID
: was
: the relational key, until it was needed for the "Contact Us" page.
: Any particular reason why it would be better to define everything up front
: on the
: Application.cfm that's needed, or does it matter? 6 of one, half
: a dozen of
: the other?
This is a question of people time vs computer time. What you suggest is
more efficient (assuming you never repeat a query, don't use multiple
queries where one would do, etc). However, grabbing everything you might
need right up front means you as a programmer don't have to do so much work
keeping track of what's already been called, etc. Also, as you make changes
to the app, you always know what's available to the application without
having to check and see if you've already grabbed that data or not. This is
a personal call as to style. I know what I prefer, but others might (and
likely would) disagree.
: Thanks for your insights...they are much appreciated.
: I've had some personal emails sent to me about this thread where
: people have stated they have been considering doing the same sort of thing
: and have enjoyed and learned from the discussion...
I've worked on something similar recently. I like the Keith's idea of
multiple application names. I'm sure I've gained something out of this, if
only by forcing myself to think about scopes in a more expressable way. :-)
--Ben Doom
Programmer & General Lackey
Moonbow Software
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
