So, then by that reational - if I test and use the startupurl with 'http://www.website.com/startup.taf' domain... then any domain var assignments there should be able to impact domain vars on http://www.website.com/index.taf.
The problem is... they don't! With the exception of writing code that sits at the head of EVERY SINGLE taf (we have 100s right now), is there no other way that Tango can essentially "preload" certain variables that are used globally in every taf on the server??! I guess my big question is can you set global/domain variables using a STARTUPURL (has anyone a proven method of doing this before), and if not, then is there another solution that someone has in mind. TIA Jim Kass Web Developer -- Forestweb: The Source for Industry Intelligence Best Content -- Most Relevant -- Best Delivery http://www.forestweb.com (310) 553 - 0008 -----Original Message----- From: Robert Shubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 7:19 PM To: [EMAIL PROTECTED] Subject: RE: Witango-Talk: STARTUPURL configuration var. A few things to note: It's generally good practice to set an additional domain variable something like: <@ASSIGN domain$vars_ok 1> Then at the top of each TAF, place an IF statement checking for @@domain$vars_ok != 1. If so, branch to your domain variable rebuild TAF. In your setup, it sounds like your domain variable set is an all-or-nothing issue. This will ensure that your variables are present before any execution occurs. The second thing to note is that domain variables are dependant on the domain which is the entire URL, including the host, thus "website.com" and "www.website.com" are two separate domains. If you're testing at one, and running your startupurl at another, you'll have the outcome you describe (and rather unpredictable results). You can use domains.ini to combine URL variations like that into one 'tango' domain, or simply use @URL to call your domain setup TAF at all possible domain variations. Robert Shubert Tronics -----Original Message----- From: Jim Kass [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 9:32 PM To: [EMAIL PROTECTED] Com Subject: Witango-Talk: STARTUPURL configuration var. I'm using dynamic DataSources... specified with domain scoped variable(s). Whent the server restarts I'm noticing strange behavior... in some cases, the domain vars die, but in most cases they are still alive. I used a taf to clear domain vars manually, and restarted the server. The STARTUPURL that I set in t4server.ini which creates the domain vars I need shows it is setting them in the log, but then when I try to use a file that requires it, it fails... another taf used to view vars shows that the domain vars are as blank as when I cleared them before the restart. If I run the taf that the STARTUPURL points to manually... it sets all the vars I want and they are accessible, and after the server is restarted, they are still alive. I'm awfully confused. The default timeout is set to 120. I'm setting a variableTimeoutTrigger to the same taf as STARTUPURL. My big concern here is that sometimes these domain vars are dying and because they are being used to indicate a database connection - pretty important things will break in the middle of the night after a server restart without my knowing... a serious problem as far as I'm concerned. I'd think that setting the variableTimeoutTrigger to the STARTUPURL taf would ensure that even if they die that they still get rebuilt, but considering that the variable assignments dont seemt to be happening anyway other than in the logs... I'm at a loss for how to ensure 100% uptime of these vars. (Maybe the ultra-unelegant solution of putting the STARTUPURL taf on a cron... hoping that it behaves differently than when the server restarts). Any ideas? Jim Kass Web Developer -- Forestweb: The Source for Industry Intelligence Best Content -- Most Relevant -- Best Delivery http://www.forestweb.com (310) 553 - 0008 ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
