This is probably the best way to manage data source information in Witango currently.
I would make one small suggestion: Use the domain scope rather than the system scope - this allows you to duplicate TAFs/TCFs to run on other sites (even development/testing/beta sites) and you can change the DS target to a specific database per domain. Or you could leave out the scope altogether and use the scope hierarchy to set data source information as you need to. To set these variables, you would need to embed them into a TAF or an include file. The include file is more convenient, but if you were to use a TAF and branch to it, you could then deploy the TAF as run-only and your data source information would be secure. I know I haven't posted much about the future of Witango, but fixing the way data sources are managed in the platform is high on my list. I intend to use some of the best ideas from Witango as well as other platforms, and develop a system that fits well with Witango's ease-of-use and gives adequate control to both the developer and the server administrator. Robert -----Original Message----- From: Dale Graham [mailto:[email protected]] Sent: Saturday, February 26, 2011 5:56 PM To: [email protected] Subject: Re: Witango-Talk: Invalid object name While I agree with you generally, there IS a work around that does very well -> for hiding deployment info in TAFs. Unfortunately, development connectors (though encrypted) are still somewhat at risk. We define system variables (e.g. variables specified in the witango.ini file) with names like DSName, DSHost, DSusername, DSpassword - the data for the database connection is specified for deployment on that particular server (so the production server's info points to production DB, development to the development DB, etc) (Multiple datasources can be specified as different variables, of course). At any rate, there's nothing in the TAF except a pointer to a variable that only exists on the server. In the taf, for the database deployment info (set this up from the Database properties, so it's used by every TAF), you just use Name <@var system$DSName> Host <@var system$DSHost> (or leave empty) User <@var system$DSUsername> Password <@var system$DSpassword> Instant switching. Handy, too, to do quick switches in DB information (e.g., periodic changes in DB passwords, etc). No changes whatsoever needed to the tafs, just to the Witango.ini file(s) affected. Works a champ. ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body. ---------------------------------------- To unsubscribe from this list, please send an email to [email protected] with "unsubscribe witango-talk" in the body.
