[Nitro] Simpler configuration method?

Michael Fellinger manveru at weez-int.com
Tue Feb 6 20:25:05 EST 2007


On Tue, 06 Feb 2007 03:29:52 +0900, George Moschovitis  
<george.moschovitis at gmail.com> wrote:

> Thanks for helping me with this. My limited knowledge of the English
> language prohibits me from explaining the inefficiencies of the current
> implementation with such a nice example.
>
> -g.
>
> On 2/5/07, Kirk Haines <wyhaines at gmail.com> wrote:
>>
>> > I still am unconvinced that there is a need to configure anything
>> > before it is instantiated (in the case of objects) or declared (in the
>> > case of classes).  Can we get a couple of examples?
>>
>> Here's the use case:
>>
>> You have a web site with public content and private content.  The
>> private content is by login only.  Your config file contains all of
>> the db connection information as well as all of your web app config
>> information.
>>
>> You are asked to write a script which checks the database for accounts
>> which have been approved, but which haven't been confirmed by the
>> subscriber, and which have been sitting for more than 96 hours.  You
>> would like to just reuse your main config file.  No sense duplicating
>> the db connect info elsewhere, right?
>>
>> But you can't because you aren't starting the entire application
>> environment -- you are just using Og, so none of the Nitro specific
>> stuff that your config file has configuration for exists.

Well, haven't said much in this discussion yet - but it certainly got me  
thinking.
Since I work on the configuration-system for Ramaze it's been a tough  
challenge, but i came up with the solution of using
a slightly modified OpenStruct called GlobalStruct, then i create an  
instance of it in the main-namespace (Ramaze::Global)

as soon as one requires the file that defines the Global it will be filled  
with the default-values.
One important thing that is especially nasty are custom classes/objects  
held in it. So I added handling of symbols/strings to all parts of the  
code that use the configuration later on.
This makes for some bloat, but in general it offers a very nice way to do  
specification of classes that are not yet instantianted/defined (similar  
to how Og uses const_missing to catch the relations, but without the magic  
;)

so, as an example:

#################################################

require 'global'

Global.setup do |g|
   g.adapter = :mongrel
   g.cache = :MemoryCache
end

# or

Global.setup YAML.load_file('conf/stage.yaml')


Where the yaml just contains an Hash like:

{
   :adapter => :mongrel,
   :cache   => :MemoryCache
}.to_yaml

# =>

---
:adapter: :mongrel
:cache: :MemoryCache

#################################################

The point is to have one central point for the configuration.

The configuration in Nitro is IMHO too tight coupled with the things that  
use them.
Providing only one point for it allows for drastic improvments in  
documentability and interfacing that configuration.

^manveru


>> Kirk Haines


More information about the Nitro-general mailing list