: When you wrote:
:
: "you should be setting request-scoped variables in
: the application file and set them for every request, not just the first
: one."
:
: Do you mean that each page of the site should re-define the request scope
: variables,
: instead of just the first page (index.cfm?) I figured that once
: I had some
: global variables
: set, I wouldn't need to run the query involved for each page. For the
: topgraphic, say,
: I was just running a query and getting the name of the appropriate
:graphic
: and assigning
: that name to the Application.TopGraphic variable and using an <IMG> tag to
: place
: the graphic. Are you saying allow the application.cfm to run the
: query and
: re-define
: that graphic for each page? Is that the only way to prevent users from
: seeing the wrong
: site graphics and information when the variables change?
Yes, I mean that you should, in your application.cfm file, run whatever
routines you need to get and set request-scope variables that you will use
later in your page to create whatever customizations you need. Since the
routines are located in (or are called from -- whichever works best for you)
your application.cfm file, they will be run each time any .cfm page is
called.
This is not the /only/ way to do this, but (IMHO) it is the best.
You could store this info in the session scope. I really don't see much of
an upside here unless you are running from a lousy DB (ie Access) and have
high traffic. Basically, you need to lock a section of code that does a few
things. First, check and see if some session variables exist. If they
exist, make sure they match the requested domain. If they don't exist or
don't match the requested domain, go and get the information by whatever
means you've dreamed up. Finally, copy all the information to the request
scope so that you can use it without locking each call. finally, close the
lock.
You could store this info in the client scope, but that would basically work
the same as session scope, but you don't need the locks. However, if you
use this method, you should store the client info in a designated database,
/not/ in the system registry. This means that you're still making a bunch
of calls to your db.
You should NOT repeat NOT use application scope for this. Why? You start
surfing d1.com, so d1.gif is the header and d1.css is the style sheet. Now
I show up via d2.com. I change all the application variables in the
process. This changes them for everyone, not just me. Therefore, unless
you are checking the domain on every call, you end up seeing d2.gif and
d2.css instead of the ones for the domain you requested. Remember,
application variables apply to /every/ call to that application, not just
your request.
In the end, I'd skip any attempt at persistent storage via CF and just check
the domain on every call (since you have to anyway) and either run that
against your DB or hard-code the variables or just base the images,
stylesheets, etc. on the domain name.
: Concerning the application.cfm page being accessed when I open a
: bookmarked
: index.cfm page:
:
: It wasn't accessing the page automatically. I tested this by having the
: application.cfm page
: output some variables and abort to see if it was being accessed.
: Only when
: I refreshed the
: bookmarked index.cfm did the output occur from application.cfm. That
: confuses me.
: I thought it happened automatically every time. That behavior is what I'm
: depending on.
: It may be just a localhost production behavior....
I have no idea about this. I'll let the experts handle this one. :-)
--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.
