Re: [Gramps-devel] Proposal for updating config settings

[Nick H. <nic...@ho...>]

Doug Blank wrote:
> On Mon, Oct 5, 2009 at 8:47 AM, Benny Malengier
> <ben...@gm...> wrote:
>   
>> 2009/10/5 Doug Blank <dou...@gm...>:
>>     
>>> The only existing code is the parser and writer, and we will reuse
>>> those, with a slight change.
>>>
>>> I'd rather make it just one more level abstract. That way the dev
>>> doesn't have to worry about the type, and we can swap out ConfigParser
>>> for something else if we wish (XML?). Type errors can be handled by
>>> the system, as it knows what type the setting should be. That is an
>>> error at parse time, not when you try to use the value.
>>>
>>> For example, it might be nice to say
>>> Config.get("preferences.default-person") and have that return a person
>>> object. It doesn't do that now, but I'd like to keep the interface
>>> abstract enough to allow future expansion. Also, you might want to
>>> allow sub-sub-sections someday, like
>>> Config.get("view.default.selection").
>>>
>>>       
>> I don't like this coding for future features that complicates code
>> now. Things can be changed in the future when those features are
>> actually planned.
>>     
>
> What I'm proposing makes the code now simpler, and get's rid of a lot
> of code. Recall that is the reason for this whole proposal.
>
>   
>> I rather see us using ConfigParser module
>> (http://docs.python.org/library/configparser.html ), and only deviate
>> from this is a real use case can be given to do it differently. The
>> less of our own code we need to maintain the better.
>>     
>
> Agreed.
>
>   
>> Eg, if you need a person object from something in the ini file, then
>> write a function in util.py that does that for you based on the ini
>> file setting. No need to complicate config code with person object.
>> If one needs subsections, then one can create a section [view.default]
>> and consider that a subsection.
>>
>> I agree also with what Nick says about integer/string confusion. It is
>> in the code, the ini is edited by people who know what should be in
>> it. So why do this type checking and stuff that will never be needed?
>>     
>
> I don't disagree, I just don't want to have to replicate a bunch of
> tests every time one needs to access a setting. Let's put that
> boilerplate testing in one place.
>
> Let me put some code up, and you'll see that I'm talking about a very
> thin wrapper around ConfigParser that makes it easy to use in Gramps.
>   
Yes, this is the way to go.  When I was talking about existing code I 
was meaning existing built-in python code not existing gramps code.

I think that the only code you really need is to read in default values 
and to emit a signal when a value changes.

> -Doug
>
>   
>> Benny
>>
>>     
>
>
>