Noam brought up a really great idea, as his use of language-localization is
a perfect example of the reverse process. There was a long and very useful
thread on CFLOCK (and if I remember the Ohio CFUG had some sort of
presentation recently on that topic--PLEASE someone post the notes on it!).
I'd also point out that the opposite handling of language-localization is to
generalize the fusebox index.cfm file to cfinclude a path plus the template
in question and then have mutliple language versions of the site that follow
through different paths. The drawback here is that a change in the nature of
the page, for example a new form element needs to be added, must be
perpetuated throughout the language versions. The plus side is that the
technique works without using any extra amounts of memory by holding the
translation matrix in RAM, and if you use it not for language variants
(where the formating can mostly stay constant) but rather for different look
and feels for the same site, then the redundancy is actually a benefit.
Again, it comes down to what your final use is going to be. That being said,
one could certainly use this technique for the multiple versions and then
use Noam's multilingual technique for multiple languages within each of
those multiple versions! Phew! as long as you think it out ahead of time it
works! But don't try going multi-lingual and multi-versioned in the middle
of development!! :)
----- Original Message -----
From: "BOROVOY Noam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 23, 2000 3:34 AM
Subject: RE: store global variables in db?
> In some cases it certainly makes sense storing global variables in the dB,
> though you could look at it from the other side as caching dB data in
global
> variables ;-)
> for example with our multilingual site all the labels are loaded into an
> application scope structure of arrays per language:
> #Application.labels['FR'][135]# will give label 135 in French...
>
> The whole point of global variable in dB usage is the caching for speed
(one
> dB hit per timeout of application variables) with flexibility and
management
> of data in the dB.
> There is a price to pay - you need locking - CFLOCK.
>
> HTH,
> Noam
>
> ----------
> From: John Quarto-vonTivadar [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, 23 August 2000 0:46
> To: [EMAIL PROTECTED]
> Subject: Re: store global variables in db?
>
> > The bigger focus was storing global variables in the database,
> rather than
> > hard coding them in the template, in order for them to be changed
> through
> a
> > web interface. Any potential problems there?
>
> well i guess it depends on the scope of the app. I find it just much
> easier
> to have a configuration file that sets all these variables, since
> typically
> global variables stay somewhat constant once the app gets out of
> beta.
>
> Further you are going to HAVE to use some pre-set non-DB global
> variables,
> if only to point to the datasource in which the rest of the
> variables are
> stored! :) in for a penny, in for a pound. :) Plus, as small as it
> might
> be, storing the global vars in a db does mean a hit to the db, so it
> gives
> another point of failure if the db server is a separate machine.
> Seriously,
> tho, if you had many, many such variables then I guess your approach
> can
> make some sense--I just don't see what you are saving by doing it
> that way.
>
> Now, of course, this is a different matter altogether if you are
> proposing
> storing user specific variables
>
>
> --------------------------------------------------------------------------
--
> --
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
> --------------------------------------------------------------------------
----
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
