Re: Witango-Talk: Application Scope Problems

[Robert Garcia]

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 [EMAIL PROTECTED] - [EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/ 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: <@ASSIGN user$variabletimeouttrigger value="http://<@domain>/taf/cleanup.taf?<@USERREFERENCEARGUMENT>"> 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