Roland,
You don't sound paranoid to me... I don't think it's too much to ask that you can install the same app on different virtual hosts and keep the variables separate from other apps with the same name and from other vars in the site not part of the app.
If you switch your app to use domain scoped variables and I decide to purchase your app and run it with a site here Now I have a problem if I happen to use a domain scoped variable with the same name.
/John
Roland Dumas wrote:
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:
usingRoland,
Are you using separate tafs, tcfs and tmls for each domain or are you
hitsone "copy" of them for all the domains.
If you are using one "copy", why not determine the domain when a client
manythe 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
andomains on the same server. Each would have its own application scope variables.
The experience is that application scope leaks across domains, such that
application in one domain shares variables with the same application inall
<@APPPATH>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
- create an application for each domain, with path definitions beingapplication
/forum_1/ , /forum_2/ etc
- in each domain, not use a directory that is associated with an
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
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
