Re: [Rest2web-develop] Last Commit

[Nicola L. <ni...@te...>]

>> The first one: there is no default value. There should be a way to check
>> a param's value, when it is set in the config file, or else to fill in a
>> default value when it is not. As it is, one may leave the configspec
>> empty, meaning that the value may not be present: alas, by doing so one
>> loses any check on the value, and there's no default value anyway.

> Easy - allow all the functions to take a keyword argument 'default'.
> Amend ConfigObj so that instead of automatically failing missing values
> it calls the tests with a 'missing=True' keyword.
>
> The test function can then decide if being missing is an automatic fail.
> If a default is available - then it's not.

It sounds easy enough, I'll try it.


> We *may* run into trouble with quotes in default values here, as we're
> using ConfigObj to parse the configspec. If it is a problem we'll work on
> a special mode for ConfigObj when parsing the configspec.

A few tests will highlight any problems.


>> This default value business is very handy, because it allows to specify,
>> in the config file, just the values that differ from the defaults.

> So in the configspec :
> 
> Key =  integer
> 
> Would fail if key is missing. Whereas :
> 
> Key = integer(default=3)
> 
> Would substitute 3 for missing values.
> 
> *However* - this would cause the default value to be written out by the
> ``write`` method.

That's what my ZConfig extension currently does, and it's quite ungainly.


> (Unless we create a new private Section attribute for
> 'defaults' that aren't written out unless they get set from outside the
> ConfigObj).

It would be great to carry the defaults around, and only write values to
file when they are different from the defaults. This only applies to
scalars, not to sections, obviously.


>> The second problem is deeper: the configspec is monolitic, and I need
>> it to be modular. That is, some sections contain a number of
>> homogeneous subsections, and there's no way to know beforehand how many
>> they will be. They should reuse the same configspec, so should be
>> somehow declared of a certain "type", and validation should have a way
>> to pick the right configspec fragment.
>>
>> This may be related to what you wrote:
>>
>>> Hmmm... Well I want to get validate working as a Section attribute
>>> rather than an attribute just on ConfigObj...

> In the version you now have, the configspec is a Section attribute - a
> dictionary of tests for that section.

So I can already reuse the same configspec to instantiate a Section, and
attach it to a ConfigObj? Cool.


>> ZConfig does this by reusing section types in "multisections". Probably
>> we could do something similar by validating the configspec for
>> Sections, and then composing them in the complete configspec for the
>> ConfigObj.

> You can already manually add them to a Section. You could add syntax to
> the configspec for naming and repeating them...

I'll try that.


>> If we can solve these two problems, I think we can set the Configobj
>> status straight to "beta", from my POV at least. ;-)

> Cool. Let me know your response to my suggestion. It only means using
> the existing syntax of validate.py - using keyword arguments (so only
> changing the functions). I wonder if it is too clumsy for you though ?

Not at all, I find it convenient enough, and "explicit is better than
implicit" anyway. :-)

-- 
Nicola Larosa - ni...@te...

Abstraction is layering ignorance on top of reality.
 -- rpg, cited by Richard P. Gabriel, November 2002