This is what I do

a single XML file containing the initial datasource that gets called before
the application loads.

I have an intApplication.cfc that uses that datasource provided by the XML
file to query the datasource and all my app info is in a database table.

With regards to paths.  The file is always in the same location, relative to
my application.cfm file, so i can call it no matter what the environment is.

Steve

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Stephen
Milligan
Sent: Monday, May 24, 2004 5:21 PM
To: CFAussie Mailing List
Subject: [cfaussie] RE: looking for ideas - storing config settings


One very simple way to avoid the problem is to append the version number to
the config file name.

When you release a new version, your new config file can cfinclude the
existing one at the bottom so any existing settings get used and any ones
you've added get their default values.

If you choose a purely numeric version number you can even use cfdirectory
to loop over all existing config files in order using the settings from the
oldest file last, but it's unlikely you'd need to go quite that far.

As long as you have an update script that can read the existing settings,
write them into the new config file, and remove the cfinclude at the bottom
it should be fairly straightforward.

Spike

--------------------------------------------
Stephen Milligan
Code poet for hire
http://www.spike.org.uk

Do you cfeclipse? http://cfeclipse.tigris.org




>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Aaron DC
>Sent: Sunday, May 23, 2004 11:00 PM
>To: CFAussie Mailing List
>Subject: [cfaussie] RE: looking for ideas - storing config settings
>
>Are you amenable to storing the values in a database table?
>
>I had started to develop a table with a very simple structure
>along the lines of:
>
>Table: setting:
>-------------------------
>SettingID         A++
>SettingName    VarChar 25
>SettingValue    Varchar 200 (or memo/text depending on how
>large your values are)
>
>as CF is typeless, you can store all you like in there and
>read back at application startup time.
>
>Another option is to store the XML file in the database
>directly - in a memo/text field. You don't need to worry about
>writing/over writing files or knowing where paths go or anything.
>
>Either way you can provide an SQL statement with default
>values or set them up as part of the install process. If there
>are no values present in the DB, treat it as a fresh install, etc etc..
>
>HTH
>Aaron
>
>
>
>
>----- Original Message -----
>From: Darren Tracey <mailto:[EMAIL PROTECTED]>
>To: CFAussie Mailing List <mailto:[EMAIL PROTECTED]>
>Sent: Monday, May 24, 2004 4:28 PM
>Subject: [cfaussie] RE: looking for ideas - storing config settings
>
>
>That's not what Barry is after Taco.
>What happens is that our finished apps are installed offsite
>at dozens of client sites on their machines, which are beyond
>our control.
>Drive letters, web roots, datasource names are all up for
>grabs and can change from site to site. Most sites do not put
>their apps in any subdirectory of the actual web root, but
>tend to stick them on a separate drive letter.
>What we're trying to avoid is having all these site specific
>and critical values being stored in a config file in the
>application directory, where they are at risk of being
>overwritten by the next versions install files. These files
>must be included in install files so that new installations
>get a blank version to start modifying.
>Its tricky. We've been looking at XML files stored out of the
>application's directory, but the question is where.
>A few key values (DSN, some security info, path to XML file)
>can be stored encrypted in the registry, but there's too many
>to store all of them there.
>Places I've thought of include:
> the actual web root (issues with it being browsable though)
>somewhere in the c:/cfusionmx/ directory (will future CF
>installs and updates clear this info though?)  Some random
>spot on the server's hard drive?
>
>Anyone already do anything like this or have any ideas or suggestions?
>
>Regards
>
>Darren Tracey
>Alpha Business Systems
>       -----Original Message-----
>       From: Taco Fleur [mailto:[EMAIL PROTECTED]
>       Sent: Monday, 24 May 2004 4:06 PM
>       To: CFAussie Mailing List
>       Subject: [cfaussie] RE: looking for ideas - storing
>config settings
>
>
>       Personally what I do is the following;
>
>       I structure my directories like the following
>       d:\inetpub\wwwroot\internet\development\{app name}
>
>       Then in the application.cfm I do
>
>       <cfset request.pathRoot =
>getDirectoryFromPath(getCurrentTemplatePath())>
>
>       <!--- check what phase the application is in --->
>       <cfset position =
>reFindNoCase("(development|testing|staging|production)",
>cgi.path_translated, 1, "true")>
>       <cftry>
>        <cfset request.applicationPhase =
>mid(cgi.path_translated, position.pos[1], position.len[1])>
>        <cfcatch>
>         <h1>Application mode could not be found!</h1>
>         <strong>You need to set this manually</strong>
>        </cfcatch>
>       </cftry>
>
>       This will get me the path and tell me what application
>settings to use.
>       request.applicationPhase will determine what to use,
>for example for the DSN etc. I do
>
>       if ( NOT isDefined("application.setting") )
>       {
>        setting = structNew();
>        structInsert(variables.setting, "applicationName",
>request.applicationName);
>        structInsert(variables.setting, "dsnMain",
>"dsn#variables.setting["applicationName"]#_#request.application
>Phase#");
>        structInsert(variables.setting, "imageRoot", "image/");
>        structInsert(variables.setting, "mapping",
>"/#variables.setting["applicationName"]#_#request.applicationPhase#/");
>        structInsert(variables.setting, "dateFormat", "dddd,
>dd mmm yyyy");
>        structInsert(variables.setting, "timeFormat", "H:mm");
>        application.setting = duplicate(variables.setting);
>       }
>
>       Then I also read an XML file into the application scope
>which will contain several variables specific to each phase, example;
>
>       <cffile action="read"
>file="#request.pathRoot#\variable_#request.applicationPhase#.xm
>l" variable="xmlVariable">
>
>       In short I never ever have to change anything upon
>moving the application from development to testing etc.
>       Does that help?
>
>       PS. I have a doco that sort of describes some of these
>things... Not that anyone is interested ;-))
>
>               -----Original Message-----
>               From: Barry Beattie [mailto:[EMAIL PROTECTED]
>               Sent: Monday, 24 May 2004 3:49 PM
>               To: CFAussie Mailing List
>               Subject: [cfaussie] looking for ideas - storing
>config settings
>
>
>               Hi all
>
>               Any advice on where is a good place to store
>config settings for multiple apps? Our many clients have
>variaing configurations. It would be one file for all app settings.
>
>               we're probably going to end up using the
>registry for DSN passwords, etc, but how about other things -
>paths, names, defaults, etc? Some of these will have to be
>calculated and written at first run, or in some cases, prompt
>the user for any missing values and then write them. I suppose
>it'd be like a simple installer program.
>
>               Application vars would only be available per
>app, not across all of them. Server vars seem interesting but
>they'd have to persist on re-boot and I'm not sure how they'd
>work on clustering.
>
>               Chances are XML files are the best way to store
>it but where should they go?
>                - In the webroot? - not all installs have a
>"webroot" as such, some have CF mapped directories.
>                - Inside C:\CFusionMX somewhere? could we
>trust that path would always exist? Hmmm.
>
>               at least these are all windows machines.
>
>               any suggestions?
>
>               thanx
>               barry.b
>
>
>               ---
>               You are currently subscribed to cfaussie as:
>[EMAIL PROTECTED]
>               To unsubscribe send a blank email to
>[EMAIL PROTECTED]
>               MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
>               http://www.mxdu.com/ + 24-25 February, 2004
>       ---
>       You are currently subscribed to cfaussie as:
>[EMAIL PROTECTED]
>       To unsubscribe send a blank email to
>[EMAIL PROTECTED]
>       MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
>       http://www.mxdu.com/ + 24-25 February, 2004 Register
>now for the 3rd National Conference on Tourism Futures, being
>held in Townsville, North Queensland 4-6 August - www.tq.com.au/tfconf
>
>---
>You are currently subscribed to cfaussie as:
>[EMAIL PROTECTED] To unsubscribe send a blank
>email to [EMAIL PROTECTED]
>MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
>http://www.mxdu.com/ + 24-25 February, 2004 --- You are
>currently subscribed to cfaussie as: [EMAIL PROTECTED] To
>unsubscribe send a blank email to
>[EMAIL PROTECTED]
>MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
>http://www.mxdu.com/ + 24-25 February, 2004
>


---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004


---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]

MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to