Hi, Keith. The answers in here were answered in Ben's further elaboration on the topic.
Thanks for all your help! Rick -----Original Message----- From: Rick Faircloth [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 12:34 PM To: CF-Talk Subject: RE: One dynamic site for multiple indepentdent businesses Thanks, Keith! That helps a lot. I hesitated to even send my email with all the questions for fear I would "overstay my welcome" on the topic and abuse your and other's generosity. I appreciate so much your taking the time to put together such a detailed explanation. I know there are others of us who haven't used scope variables beyond perhaps "session.password" and "session.username" very often and have benefited from this discussion. I'll put your advice and guidance to good use. I especially like the explanation about the dynamic application name. Never really knew what the name had to do with anything. I guess since the handling of those structures is done by CF "behind the scenes" I never knew what that name did. Now I know it defines the application variables that are created by the <CFAPPLICATION> tag. Is the same thing true for the session variables that when SessonManagement is enabled as part of the <CFAPPLICATION> tag? Is the info in the Session structure defined with the <CFAPPLICATION> Name? Using CF 4.5.2, is there a way for me to "cfdump" the variables in those structures to actually see how CF defines them according to the <CFAPPLICATION> Name? Thanks, again. Rick -----Original Message----- From: Keith Dodd [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 03, 2002 10:08 AM To: CF-Talk Subject: One dynamic site for multiple indepentdent businesses I'll see if I can hit main points. (Keep in mind, I've done this, but am far from CF expert category. So, this is all just a method that has worked for me!) 1. If the application name is not dynamic, then each user would overwrite and you'd just have one site--not the many you want. If I understand correctly, you want one set of code to *make* several sites, each with unique info, look, etc. That's why the BusinessID (or whatever) is critical. 2. By making application name dynamic, (as in name="MyApp#request.BusinessID#") each set of these application variables will be *tied* to a certain site. If application-scoped data is already available (from a previous user) for SiteA; if I come and request SiteA, the existing app data will be used--fine because that's the site I wanted. If I come, however, requesting SiteB, it will either find app stuff for siteB or if it's not there, call the script to create it. Now we have two sets of app data available to users. Etc. Note: With this set up, there is no application data that is tied to the generic site--unless you have that too as another set of data. (At least that's how I think it works.) 3. All the <CFSet Request.stBusinessInfo = Duplicate(Application.stBusinessInfo)> does is put the info into a scope you can call without locking worries (at least that's all I think this accomplishes). Note: The app info that's duplicated will be unique based on the site requested via the BusinessID. 4. Although the application info is not tied to something like the user having a session, the user will continue to get the application (converted to request) info for the chosen site because that ID number routine is always being set. If you needed to set a session for the current user, that session would be tied to the particular application name. (If person with a session variable on SiteA moved to SiteB, the person would not have that created session variable. If they go back to A--before a timeout--they'd be back in A's session.) Don't confuse, however, the unique application/request info with a session. 5. I lock app and session variables--appropriate for readonly or exclusive when using them. Even though now moving to MX, I continue to do it. (not sure I have to in all cases, but seems like good idea) 6. I create upfront a structure that holds just about all the variables I'll need for a site. That way it's always done and available anywhere on the site. Page color, stylesheet variables, names, addresses, etc. This structure includes about anything that won't be queried dynamically for a specific user request, such as seeing all the employees in human resources. Here, query directly or use cached queries with the BusinessID allowing you to select only persons in the SiteX company. (If want more clarification, perhaps email off list) Keith Dodd 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
