[Nitro] Simpler configuration method?

nitrojesus.5.pistos at geoshell.com nitrojesus.5.pistos at geoshell.com
Mon Feb 5 13:47:09 EST 2007


On 05/02/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:
[snip]
> 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.

<Pistos> Okay, I see the use case, but I still don't see why, at the
time Og the class is created, or an Og instance is instantiated -- at
that time, load the config.
<Pistos> Say, perhaps, inside the nitro.rb of "require 'nitro'" and
the og.rb of require 'og'.
<Pistos> It's just mystical to me...  It's kind of like talking about
how you drove from California to Houston in a car you didn't buy yet.
:P
<wyhaines> No.  Think of it as a big book of recipies.  Some of them
are for things that use the stove top, and some of them are for things
that use the oven.  But both live in the same book.
<wyhaines> Your thinking is that the configuration should just
logically be separated so that the db configs are in one place and the
web framework specific configs in a separate file, right?
<wyhaines> Then it would just naturally eliminate this issue, right?
<Pistos> Maybe, if it's necessary to do so, then we should. I'm no
expert, but isn't the problem you cited above an instance of coupling?
i.e. you're trying to do Og stuff, and this other Nitro stuff is
KrazyGlued to it, so it has to tag along, even though you don't want
it.
<wyhaines> I'd say the current config situation is an instance of
tight coupling, because the configs are glued right to the things that
use them.
<wyhaines> What george wants is loose coupling.  The configs are
floating out there in ruby-space, and the things that need them can
find what they need while the ones that aren't needed are just
ignored.
<wyhaines> I agree with that position.
<Pistos> Right. We want them loosely coupled between domains, but
tightly between the config and the config-needers.
-*- Pistos reads
http://en.wikipedia.org/wiki/Coupling_(computer_science) to refresh
his memory.
<wyhaines> They are just config settings, and there is no real cost to
having settings available that are not used, while there is a lot of
convenience to having whatever configs one needs available without
really having to think about it.
-*- Pistos nods.
<Pistos> I don't have issues with that.  However, you just said that
it's a problem that we are trying to do some Og stuff, and all of
sudden this Nitro stuff is tagging along, but it "can't fit through
the doorway", because the Nitro scaffolding hasn't been setup yet. If
I am doing Og stuff, I expect that nearly nothing about Nitro should
stand in my way.
<wyhaines> I think $global_soup is not a good way to do it, though.
If I were doing it (and, well, I have already done it), I'd put the
configs under a high level namespace, like Nitro.  I'd have some
minimal class that guarantees that the config space is setup properly,
and it would have to be required before any config manipulation takes
place.
<Pistos> See, I can completely agree with all those points.
<wyhaines> Right.  The current Nitro/Og setup has exactly that
problem, because there is a tight coupling between Nitro and its
configs, and Og and its configs.
<wyhaines> So one files that sets configs has to expect that there be
all the goodies for Nitro and Og already loaded.
-*- Pistos nods.
<wyhaines> One can work around that, to some extent, by doing what I
think you suggested, which is to have separate config files for Nitro
and Og.  Require both for your web app config.  Require only the Og
file for standalone scripts.
<Pistos> Exactly.


More information about the Nitro-general mailing list