The Siesta::Config morass

[prev] [thread] [next] [lurker] [Date index for 2005/01/26]

From: Richard Clamp
Subject: The Siesta::Config morass
Date: 23:08 on 26 Jan 2005
While I'm quite happy with the $config as a global object thing, there 
are a couple of things about the configuration system that I've come to 
realise were bad hacks.

First up, the whole notion of creating lib/Siesta/ from a 
template was batshit, or rather what it grew into was.  The problem we 
were trying to tackle, iirc, was the one of "hey, we'll have external 
resources, and people will want to choose where to put them, so let's 
let them do that at Makefile.PL time".

Then it grew so rather than containing one single path, it was paths 
for everything, just in case you wanted to put your message templates 
here, and your archives there.

Oh, and then we wanted to parameterise the database.

And thus was born the second cause of pain.

Because I'm a lazy guy, and really didn't want to specify things twice, 
I wanted the database backed classes to use Class::DBI's set_up_table 
introspection to set up the classes.  But annoyingly, this has to 
happen at compile time.

Of course, the problem with that is if you want to override the config 
after that, which you typically do if you're taking command-line 
parameters you have to perform all kinds of nasty to defer the compile 
time of the database classes (witness nacho).

Oh, and thirdly I think AppConfig turned out to be something of a pup, 
but that's possibly still down to the usage it got.

So, how to fix this?  I think have a couple of options.

* have /etc/siesta.conf ~/.siesta.conf $ENV{SIESTA_CONF} all imported 
and merged together, once, at compile time.  nacho could cheat by 
renaming itself nacho-real and having a new accomplice that just parses 
the -f option and passes everything else through

* Lose set_up_table and replace it with some kind of mechanism for 
parsing the DDL in Siesta::DBI to create the objects accessors.  Or 
steal a page out of Class::Persist's simple_db_spec method.

* I'm also mindful of not having two config files, as we now have with 
Log::Log4perl.  I have a hunch that I can inveigle siesta.* directives 
into the same config file as Log4perl uses, which would be better, but 
I need to read some docs or hack on it to know.

Opinions? Patches?

ps, I've rejoined the #siesta channel and will be there 
for as long as my interest holds.  Get in fast...

Richard Clamp <richardc@{,}>

Generated at 02:00 on 09 Mar 2005 by mariachi 0.52