Hi, Keith.

Yes, that helps.  Now we're getting to the area of CF where my
knowledge and understanding is weakest:  Scope Variables.

I've used them in limited ways before, mainly session variables
for password and username authentication, but not in this way
and this extensively throughout the site.

Let me see if I understand something about the different types of
scope variables and the Name attribute of <CFAPPLICATION> tag.

1)  If the Name of my CFAPPLICATION is the same for each business,
     then I risk users overwriting each other's variables.

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?
     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?

3)  Even if statement 2 is true, change all application variables to request
variables
     for use throughout the site?


Concerning Session, Application, and Request scope variables:

1)  Application variable access are not specific to a particular user's
session on the site?
     And, therefore, a specific variable *can* be overwritten by different
users within other users' sessions?

2)  Session and Request variables are specific to a particular user's
session on the site?
     And, therefore, a specific Session or Request variable *cannot* be
overwritten by different users within other users' sessions?


Concerning Locking:

1)  Application variable need to be locked.

2)  Request variables do not.

3)  What about Session variables?


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 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?

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...

Rick



-----Original Message-----
From: Keith Dodd [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 6:53 AM
To: CF-Talk
Subject: One dynamic site for multiple indepentdent businesses


Perhaps would be helpful to point out that in my similar application, at
least, in application.cfm page, I also key the application to the ID, as in:
<CFAPPLICATION  Name="MyBusiness#Request.BusinessID#"
sessionmanagement="yes" sessiontimeout="30"> (So, each "site" is a separate
application even though using only one set of code/templates.)
Then see if an application structure already exists (created from a series
of queries to set a structure that includes all the unique info for that
specific entity). (Use appropriate locking procedures.) If the
application.structure exists, then duplicate it to request scope.
If application.structure does not exist (or isn't for some reason a
structure), go and run the procedure that sets up the structure, making it
an application structure, then duplicate it to request scope.
So, each page call is duplicating the basic informational structure into
request scope (setting it up first if not available). This make the
informational structure appropriate to the identified business available to
any page called, and can be referenced as in:
#request.stBusinessInfo.City#, #request.stBusinessInfo.State# (no need for
locking as not in session or application scopes). You can also use cfdump
(cf5 or later--or use the custom tag if before) to *see* this structure
request.stBusinessInfo.

Hope this gives a little more to help you develop your application.

Keith Dodd
[EMAIL PROTECTED]
www.wingserv.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm

Reply via email to