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
