Re: [Rest2web-develop] Last Commit

[Michael F. <mi...@pc...>]

Hello Nicola,

-----Original Message-----
   >From: "Nicola Larosa"<ni...@te...>
   >Sent: 07/08/05 19:21:19
   >To: "res...@li..."<res...@li...>
   >Subject: Re: [Rest2web-develop] Last Commit
   >
   >Some work done this weekend. I'll refer a few times to ZConfig, please bear
   >with me. ;-)
   >
   >First, I committed the files from your email.
   >
   >Then I fixed the doctests for both configobj.py and validate.py to make
   >them work on Python 2.2.3 . I even tried Python 2.1.3, but it would have
   >taken too many changes, so I dropped it. Only one test, for validate.py,
   >still fails on 2.2.3, for trivial reasons.
   >

Cool - nice one.

   >Finally I converted a rather elaborate config file from ZConfig format to
   >Configobj. All is well as far as values go, but I have two non-trivial
   >problems with validation.
   >
   >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.

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.

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


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

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

   >By the way, maybe you could give a look to the ZConfig doc PDF, if you
   >didn't already. There may be some good ideas in there, amidst all the
   >formality ;-) :
   >
   >http://svn.zope.org/*checkout*/ZConfig/trunk/doc/zconfig.pdf?rev=30398
I will do.

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

Regards,


Fuzzy
http://www.voidspace.org.uk/python 

   >-- 
   >Nicola Larosa - ni...@te...
   >
   >Abstraction is layering ignorance on top of reality.
   > -- rpg, cited by Richard P. Gabriel, November 2002
   >
   >
   >
   >
   >-------------------------------------------------------
   >SF.Net email is Sponsored by the Better Software Conference & EXPO
   >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
   >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
   >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
   >_______________________________________________
   >Rest2web-develop mailing list
   >Res...@li...
   >https://lists.sourceforge.net/lists/listinfo/rest2web-develop
   >
   >