----- Original Message -----
Sent: Thursday, August 17, 2006 9:35
AM
Subject: Re: Witango-Talk: Application
Scope Problems
You know, I have found, the most reliable method, is to have
include file, on every page, that checks any objects, or application/domain
scope vars, and initializes as necessary.
So, this include tml, will check if your vars contains, what they are
supposed to, and if they don't, it calls methods to initialize them. We have
found this to be completely, reliable, here is a sample, of a global object,
being checked, and it leaves html comments in the page, for debugging:
<!-- Check BigHead Widgets Start Timer: <@timer> -->
<@if "<@var bighead$widgets type=text> contains
'object'">
<!-- Just Checking the BigHead Object Status
Listener Address: <@var system$listenerAddress>
Current Object: <@var bighead$Widgets>
-->
<@else>
<@assign bighead$widgets <@CREATEOBJECT OBJECTID="bhwidgets.tcf"
TYPE="TCF">>
<!-- Just Creating the BigHead Object Status
Listener Address: <@var system$listenerAddress>
Created Object: <@var bighead$widgets>
-->
</@if><!-- Check BigHead Widgets End Timer: <@timer>
-->
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
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
