----- 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
