|
Great this seems to be the solution thanks again
for all the help everyone
john michelin
----- Original Message -----
Sent: Thursday, August 17, 2006 9:29
AM
Subject: Re: Witango-Talk: Application
Scope Problems
the documentation (help screens) indicate that the timeout
trigger can be set in any scope and specifically says application scope. But
the default is that domain scope variables don't expire, and I think
application scope is the same. timouttriggers are then moot. Again, I use the
function only for user scope timeouts and it works fine.
When I launch apps the first time, all the domain or app scope variables
are missing. I put the initiation of those variables in a startup taf.
In the case of a witango crash, the startup taf runs and everything is in
place. No need to check within the actual application.
If you have need of timeouttrigger in app scope, maybe there is something
that is killing your app scope variables that needs debugging.
On Aug 17, 2006, at 9:01 AM, John Michelin wrote:
I see, I was hoping not to have
all those tests in every taf, depending on the server to care for itself a
bit more then I should have probably. This used to work in tango 4. I am
wondering if its that the app is set up incorrectly, the guy at the remote
location did the actual install, so next remote desktop session I will see
if I can verify its installation.
Also the applications.ini file
looked different then I remember
- [Applications]
Default=This application
controls everything in the web root which is not part of another
application.
Storefront=This application is
for the takeout storefront
-
- [Default]
PATH=/
CUSTOMSCOPESWITCH=on
EXTERNALSWITCH=on
FILEDELETESWITCH=on
FILEREADSWITCH=on
FILEWRITESWITCH=on
_javascript_SWITCH=on
JAVASWITCH=on
MAILSWITCH=on
PASSTHROUGHSWITCH=on
-
- [Storefront]
PATH=/StoreFront/
CUSTOMSCOPESWITCH=on
EXTERNALSWITCH=on
FILEDELETESWITCH=on
FILEREADSWITCH=on
FILEWRITESWITCH=on
_javascript_SWITCH=on
JAVASWITCH=on
MAILSWITCH=on
PASSTHROUGHSWITCH=on
the
timeoutTrigger is set in user scope and determines what app is triggered
when the user scope times out. For instance:
can be used to launch the cleanup task that purges all the rows in a
table relating to this user's visit.
using this to create application variables doesn't make sense unless
you want to do something to those variables as a consequence of the user's
variables expiring.
If you want to set/clean up app scope variables, then you should put
a test in the beginning of your logic that looks for the application
variables and if they don't exist, sets them.
On Aug 16, 2006, at 12:40 PM, John Michelin wrote:
You may
not set the configuration variable (variableTimeoutTrigger) in the
(application) scope.
Consult
the documentation for a list of valid scopes that can be used with this
variable.
I
receive this message after trying to set the variableTimeoutTrigger in a
class file that sets up/resets the application variables. Am I missing
something?
John
Michelin ________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango..com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
|
