Re: config -> data overloading (was Re: docs: how to upgrade plugins for 1.2)

On 02/28/05 22:31, will guaraldi wrote:
> On Mon, 28 Feb 2005, Steven Armstrong wrote:
>>
>> Anyway, this issue pointed me to another problem.
>>
>> In the wiki [1] someone points out that the way config and data are 
>> overloaded (he calls it shadowed in the wiki) is inconsistent, and he's 
>> right.
>>
>> In the default blosxom renderer, while processing head and foot 
>> templates, data overloads config, which IMHO makes sense. But while 
>> processing entries, config overloads data.
>>
>> I'ld like to propose the following rules/changes:
>> - Pyblosxom should treat the config dict as static final constants and
>>   not change it at all.
>> - any changes that need to be done to variables which are defined in
>>   config should be stored in data.
>> - data should always overload config.
> 
> Hrm...  That gets a little dicey.  It would require plugins to check the 
> data dict for variables they might need and if it's not in there, check 
> the config dict.
> 
> Right now, we change values in the config dict as we go through 
> processing.  I think (and this may be incorrect) we have a copy of the 
> config dict for each Request object--so our modified version isn't shared 
> between requests.  If that's not true, we need to fix that soon.
> 

As with the last problems it doesn't show with CGI. It's only an issue
with mod_python/twisted. I'ld have to make a copy of config dict in
Request.__init__ instead of directly using the given one. This would be
a quick'n easy fix.

On the other hand I generally sort of dislike the idea that a program
changes what I have defined in a config file.

> 
> Hmmm...  I like the idea of having a static final config dict.  Maybe the 
> data dict should start out as a copy of the config dict.  Then we fix 
> everything to manipulate and query the data dict and only look at the 
> config dict when we absolutely have to have the original values--and even 
> then we won't write to or modify the config dict.  It'll be a pain in the 
> ass to update all the plugins out there.  This would constitute an API 
> change.
> 

Grep'ing through the code base only shows a few places where config is
changed. These are all in /pyblosxom/Pyblosxom/pyblosxom.py:
config['pyblosxom_name'] = "pyblosxom"
config['pyblosxom_version'] = VERSION_DATE
config['base_url'] = config.get('base_url', '')
# plus a version of the above where base_url is generated
config['blog_title'] = '%s : %s' % (config['blog_title'], data['pi_bl'])

The only place where the config dict is actually changed is blog_title.
All others are "fallback to default cause not defined".

Also the comments plugin checks the config and assigns default values if
necessary. But this isn't a problem as these variables are
plugin-specific. What a plugin does with it's own config is not
Pyblosxom's problem.

Grep'ing through all plugins I have on my machine shows a similar
picture. They're all only interested in setting defaults for their own
config variables.

> Out of curiosity, other than a consistency issue which seems pretty minor 
> in the grand scheme of things, is there any other reason why what we're 
> doing now is bad?
> 
> /will
> 

The reason I proposed this change is:
I'm having issues with mod_python/twisted caching changes to the config
dict. For example with how config['blog_title'] is set. I thought I had
solved that problem a while back but while reading through the code
again I see that the problem remains the same.

config['blog_title'] = '%s : %s' % (config['blog_title'], data['pi_bl'])

So with this I randomly end up with a blog_title like:

My blog's title : dev/python/somepythonpost : dev/python/somepythonpost
: dev/python/somepythonpost : dev/python/somepythonpost : ..... n

For now I solve this by using:
data['blog_title'] = '%s : %s' % (config['blog_title'], data['pi_bl'])

cheers
Steven

ps: I'll download all plugins I can find and do some grep'ing on them. I
was wondering anyway how meny plugins will be affected by the changes we
allready made for v1.2.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click