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

On Tue, 1 Mar 2005, Steven Armstrong wrote:
>
> On the other hand I generally sort of dislike the idea that a program 
> changes what I have defined in a config file.

Yeah--that makes sense to me.


> 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".

We also have the issue where some people don't like how blog_title gets 
adjusted.  Maybe we should stop touching blog_title, and add to the data 
dict blog_title_with_path .  If users want just the blog_title, they can 
use that (it gets pulled from config).  If they want blog_title_with_path, 
they can use that (it gets generated by PyBlosxom and stuck in the data 
dict).


> 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.

For the record, I really appreciate that you spent time and did the 
analysis--it makes it a lot easier for the rest of us to be on the same 
page in regards to understanding the whole issue and figuring out where to 
go from here.

I'm game with not touching the config file at all during runtime for all 
the reasons you've cited:

   1. it's a problem with twisted, mod_python and other frameworks that
      cache the config dict
   2. we shouldn't be changing properties the user explicitly set
   3. there's a consistency issue with how we deal with config, data, and
      variables that get displayed in templates

I agree with the changes you've suggested:

   1. make the config dict "read-only" as a business rule
   2. change what we're doing with blog_title (though I suggest we
      add a blog_title_with_path variable to the data dict with our
      computed title)
   3. fix the consistency issue we have with blog variables

I'm game with that.  Based on Steven's analysis, it involves minor code 
changes and a "business rule".

I have one minor possible issue.  I've been advocating that people do 
fancy-ish things with their config dicts enabling them to change 
configuration variables on the fly with each Request.  For example, 
switching the num_entries property based on whether the request is for an 
rss feed or not.  I think with mod_python, twisted and the like, this 
becomes an issue because the config file isn't going to get reloaded for 
every request.  My questions are two-fold.  First, is that an issue or a 
non-issue?  Second, if that's an issue, what do we want to do about it?

Anyone else want to chime in here?

/will


-------------------------------------------------------
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