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 Get the mailserver that powers this list at http://www.coolfusion.com
