Ben, I think I'm getting the idea of the dynamics involved in this type of site. I didn't realize the application variables could be redefined for each visitor... wouldn't that cause some problems! I can see now why you've said to verify the relationship between the domain and the variables in use with every page call. It's necessary because of the complete dynamic nature of the site. That problem wouldn't show up until more than one user was accessing the site at once. Thanks for pointing that out.
I guess for now, before I get the domain names involved, I'll use the BusinessID to set the variables, then once domain are established, use those for setting the variables, including the BusinessID, which I'll have to have for relationships to a second database already in existence. I'll just have to code the BusinessID into the URL for each page, so it can be checked... I guess my biggest limitation in understanding how to code this type of app, is understanding the fine points of the various types of scopes. I'll have to do some deeper digging on those. I appreciate your help, insight, and time! Rick -----Original Message----- From: Ben Doom [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 6:06 PM To: CF-Talk Subject: RE: One dynamic site for multiple indepentdent businesses : 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
