Hey Aaron,
Thought I might add in my two bits. :)
I have used XML files before for my configuration. They work ok and can
get the job done. They pretty much fall in line with what everyone else is
saying about the INI file idea.
I'm with Matt with the H2 database idea. The last few apps that I've done
like what it sounds like you are doing, I've taken the XML file I was using
and converted it into and H2 database. The great thing about the H2
driver, if the database file doesn't exist, then it creates a new one.
This allows you to use ExpandPath and place the file anywhere you want.
Here is a great example of what I am talking about. This uses the
DatasourceCreate to create the datasource when the app is started. It then
checks for the database file. If it doesn't exists, then it runs a set of
scripts to create the neccesary tables. Also note, that with H2 databases,
you don't need to create new cfquery's for each query you run; they can all
be joined together.
<cfscript>
ds = StructNew();
StructInsert(ds, "hoststring",
"jdbc:h2:#ExpandPath('\databases')#\davisapps;AUTO_SERVER=TRUE;IGNORECASE=true;MODE=MySQL");
StructInsert(ds, "drivername", "org.h2.Driver");
StructInsert(ds, "databasename", "davisapps");
StructInsert(ds, "username", "davisapps");
StructInsert(ds, "password", "davisapps");
Datasourcecreate('DavisApps',ds);
</cfscript>
<cfif not(FileExists('#ExpandPath('\databases')#\davisapps.h2.db'))>
<cfquery name="CreateTables" datasource="DavisApps">
DROP TABLE IF EXISTS `settings`;
CREATE TABLE `settings` (
`ID` int(10) NOT NULL AUTO_INCREMENT,
`NAME` varchar(45) DEFAULT NULL,
`VALUE` varchar(45) DEFAULT NULL,
PRIMARY KEY (`ID`)
);
CREATE INDEX IDX_SETTINGS_ID ON settings(ID);
CREATE INDEX IDX_SETTINGS_NAME ON settings(NAME);
.....
</cfquery>
</cfif>
At this point, as Matt said, you could run them through a setup wizard. I
personally think that is the easiest way to get the job done. I have seen
too many times in my "day job" where people are asked to modify something
"simple" and it turns into a disater. Here is a great quote that I came
across a bit ago that kind fits what we are talking about.
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete fools.
-Douglas Adams (1952-2001)
Good luck!
Ben
On Sat, Mar 17, 2012 at 11:29 PM, Aaron J. White <[email protected]> wrote:
> @Matt: Well, I'm not against having it be a .cfm file at all. That's
> my current solution :). I was just asking if someone knew of an even
> cleaner method than the one I posted at the top of this thread. I was
> kind of hoping I had missed something, but I guess not.
>
> Thanks guys!
>
> On Mar 18, 12:02 am, Matthew Woodward <[email protected]> wrote:
> > On Sat, Mar 17, 2012 at 8:37 PM, Aaron J. White <[email protected]>
> wrote:
> >
> > > @Matt: I don't want the .ini file in a directory where it can be
> > > browsed. That's what I was referring to.
> >
> > OK, but I think you're painting yourself into a corner.
> >
> > You want a file that's in the web root, but that's not browseable, and
> > that's not CFML? Unless you get into additional configuration with
> > .htaccess as Alan mentioned, I'm not seeing a workable solution given
> those
> > criteria.
> >
> > > Also, one important goal to
> > > me is for the application to be very simple. Just like some of the php
> > > apps I have used.
> >
> > But how do those PHP applications not let you browse the file? That's the
> > key here and I don't see why things are any different in the CFML world
> > than they would be with PHP.
> >
> > In most PHP apps I've dealt with that have the type of configuration file
> > you're describing either A) the file is a PHP file (and therefore you can
> > control what's displayed if someone does browse to it), or B) they
> > recommend you delete the file once it's been read once and the
> > configuration settings are stored in a database.
> >
> > For that matter why use a configuration file at all? Assuming your
> > application has a database of some sort, why not create a "first run"
> > wizard and have them input any configuration they need to in a web form
> and
> > store that either in a database or a file that isn't browseable?
> >
> > Also why can't the config file be a file with a .cfm extension even if
> the
> > bulk of it isn't CFML if the intent is to make it easily editable by
> > non-technical people? (But frankly if your aiming this at non-technical
> > people asking them to edit a file seems like a bad move to me.) At least
> > that way it would get processed by the engine if someone tried to browse
> to
> > it and you could simply put CFSILENT at the top and nothing would get
> > displayed even if someone browsed to it. This is a pretty common trick
> with
> > XML configuration files in the frameworks (config.xml.cfm) to get them
> from
> > being displayed if someone browses to it.
> >
> > And of course you can handle this in a ton of different ways if you get
> > into additional configuration either through .htaccess or web server
> > configuration but since that's something you want to avoid, I'm just
> > curious why you think you're in such a different boat from the PHP
> > applications that do things like this.
> >
> > > Drop the application contents in your web root,
> > > change a few settings in the config file. Done!
> >
> > I get the concept. I just think from a technical standpoint you need to
> > adjust your expectations a little (at a minimum make the file have a .cfm
> > extension so you can control the output) or use a database instead of a
> > config file, which for non-technical people is a much better solution
> > anyway.
> >
> > Remember that the H2 database is included in OpenBD and could be
> > pre-configured to require zero setup on the user's part.
> >
> > --
> > Matthew Woodward
> > [email protected]http://blog.mattwoodward.com
> > identi.ca / Twitter: @mpwoodward
> >
> > Please do not send me proprietary file formats such as Word, PowerPoint,
> > etc. as attachments.
> http://www.gnu.org/philosophy/no-word-attachments.html
>
> --
> online documentation: http://openbd.org/manual/
> google+ hints/tips: https://plus.google.com/115990347459711259462
> http://groups.google.com/group/openbd?hl=en
>
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
