The problem is that app scope is behaving like a custom scope - available in all domains rather than being restricted to each... Definitely don't want custom scope. It's less restrictive than domain scope by design.
My workaround is functional, but I really don't like the idea that these variables are available in another domain. For instance, if I have a /forum/ in one domain/virtual host, and I'm keeping a list of recent posts and current visitors in application scope arrays, then someone in another virtual host might create a /forum/ folder and have access to these arrays, which could be a breach of privacy. So I have to actually create the /forum/ directory in the second domain and have the server redirect it to another folder to keep anyone from accidentally accessing the variables that might be bouncing around there. I know it sounds paranoid, but variables shouldn't be available outside of the bounds of their scopes. On 11/29/04 9:34 AM, "Fogelson, Steve" <[EMAIL PROTECTED]> wrote: > Roland, > > I'm not an expert with application variables, but there was discussion a > couple weeks ago concerning application vars expiring when they were not > supposed to. The solution that was suggested and used was to convert to > custom scoped variables. This would solve your domain issue and probably > prevent any expiration problems. > > If you have a class file that each browser request hits, you could declare a > custom scope there. Until you adopt the strategy that was mentioned before, > you could modify this class file for each domain to specify this custom > scope. OR you could use Scott Cadillac's domain custom scope XML lookup. > > If you used the custom scope now, it would cause you less coding changes > later on when you adopt the one "copy" strategy. > > Domain variables might work as well, but I don't have any experience there > as well. > > Hope this helps. Maybe someone else has a better idea. > > Steve > > > -----Original Message----- > From: Roland Dumas [mailto:[EMAIL PROTECTED] > Sent: Monday, November 29, 2004 11:18 AM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Same application name, different domains: > worka round > > > Separate tafs, etc. Copy the whole folder into each domain. > > I understand, but not quite there with your strategy. In a perfect world, > one copy of the tafs could be used with many sites, each with its own > formatting and database. I'll get there eventually, but right now, just want > to clone a directory, move to a new site, and have the application scope > variables in that new directory not comingle with the same named application > scope variables in other domains. > > > On 11/29/04 9:01 AM, "Fogelson, Steve" > <[EMAIL PROTECTED]> wrote: > >> Roland, >> >> Are you using separate tafs, tcfs and tmls for each domain or are you > using >> one "copy" of them for all the domains. >> >> If you are using one "copy", why not determine the domain when a client > hits >> the site and assign a site id and use it for accessing custom scoped >> variables that define the database to access, site template, css, scripts, >> etc. >> >> A number of developers in this group use this with great success. >> >> Steve Fogelson >> Internet Commerce Solutions >> >> -----Original Message----- >> From: Roland Dumas [mailto:[EMAIL PROTECTED] >> Sent: Monday, November 29, 2004 10:46 AM >> To: [EMAIL PROTECTED] >> Subject: Re: Witango-Talk: Same application name, different domains: >> workaround >> >> >> >> I intended to create an application /forum/ that could be dropped into > many >> domains on the same server. Each would have its own application scope >> variables. >> >> The experience is that application scope leaks across domains, such that > an >> application in one domain shares variables with the same application in > all >> domains. That's the described behavior of custom scopes, not application >> scope. >> >> After walking through the rather terse documentation and the mailing list >> archives, I couldn't find a hint as to how to keep application scope >> variables within each domain, so I had to create a workaround: >> >> - change all path designations in the application from /forum/ to > <@APPPATH> >> - create an application for each domain, with path definitions being >> /forum_1/ , /forum_2/ etc >> - in each domain, not use a directory that is associated with an > application >> in another domain. >> >> Clarification as to what should be the behavior of app scope variables is >> requested. >> >> >> ________________________________________________________________________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> ________________________________________________________________________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> > > > ----------------------------------------- > Roland Dumas > Roberts Information Services > 310 W. Bellevue Avenue > San Mateo CA 94402 > 650-347-1373 > 415-412-9300 (cell) > [EMAIL PROTECTED] > SMS: http://new.servqual.com/html/sms.tml > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
