[thelist] CF: Determining which DB used.

[.jeff]

raymond,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Raymond Camden
>
> Security reasons. That's the official reason.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

bah.  i can query the information directly by hand typing in these variables
with dots in them.  unless there is additional, undocumented variables that
would be exposed by the server scope being a structure, i see no security
risk.  power to the developer, right?

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Personally, I don't agree that it's a good idea, but,
> what do you do.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

send an email to wish-coldfusion at macromedia.com i guess.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> If you want to use the Server scope for your app, I
> suggest doing Server.App instead of just Server, that
> way you can examine the structure w/ StructKeyList, etc.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i see no indication that server.app exists.  are you suggesting
reconstructing the dotted variables into your own structure (which also has
a dot in the variable name, tsk tsk)?  if being able to walk the collection
is important to the functioning of an app, then i agree that recreating the
information as a true structure of structures would be the best route.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> [...] if you keep your queries in custom tags, it gets
> even easier.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

or even just regular includes.  i personally don't much care for the
performance hit of custom tags for the negligible efficiency gain,
especially in situations where the custom tag is called more than once or
twice as the performance loss is multiplied by the number of times it's
called.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > something else to keep in mind -- always use a global
> > variable for your local file path root. [...]
>
> I've done the same type thing you describe above, but I
> find that it runs into problems when you update your
> server. Imagine this. At your dev server, you have set
> the web root to d:\web. Your live server uses e:\web.
> Before uploading, you 'fix' the var, upload, then
> correct it back on your home system. Obviously, not a
> good idea.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

yes, i've run into this problem before.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> So, first, look for ways around it. You can, for
> example, use ExpandPath(".") to get the current
> directory you are in.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i notice you don't expand on this a whole lot.  that's probably for the same
or similar reasons i've never ended up using it in my development -- you
still have to know structure of the site you're building and have to pass
the ExpandPath() function a relative path.  in my experience, relative paths
aren't quite as easy to discern the actual location as opposed to mappings
or absolute paths.  i suppose if i messed around with it some more i could
probably come up with an elegant solution that would end up using the
ExpandPath() function.

good tip on using '.' as the relative_path argument of the ExpandPath()
function.  i hadn't thought to use that to get the current directory.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Another option: You can separate your vars and system
> level stuff into two files. So, file one has a set of
> variables that always apply. Ie, Application.BGCOLOR =
> "green". File 2 has stuff like Application.Root =
> "c:\web". So, when you deploy from Dev to Live, you
> can upload everything but file 2. I've also used .ini
> files to store this kind of information.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

yes, this is another option and the one i've used more commonly when in a
staged production environment.

Thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/