configobj-develop

[Configobj-develop] validation question

[Chris J. <cm...@te...>]

Hey

I'm using the excellent validation features to convert config files into
the correct types, and it's working very well so far. I hacked something
up that generates the configspec on the fly based on my own internal
tree of default values, which has been a nice timesaver.

However, I'm now trying to extend my application and I'm struggling to
conceptualise how I'm going to validate the config (and more
importantly, convert the types automatically).

The problem is that the config section for the new feature is recursive.
It's intended to describe a particular layout of widgets in my
application, so the same layout can be recreated when starting the
application.
(the application is a tiled terminal emulator,
http://www.tenshu.net/terminator)

The config structure would be something like:

[layouts]
  [mydebugginglayout]
    [window0]
      type = Window
      [child1]
        type = Terminal
      [child2]
        type = VPaned
        [child3]
          type = HPaned
            [child4]
              type = Terminal
            [child5]
              type = Terminal
        [child6]
          type = Terminal

I'm not super happy about the windowN/childN section names, but storing
those as lists doesn't seem to fit the configobj style, so I'm expecting
to autogenerate them.
Given that this can essentially nest infinitely, how would I write a
configspec for it?
Would it make more sense to store the children of each level as a list
and treat it as a string, then recursively validate each child object?

I'm not sure that any of what I've just written makes sense, let me know
if I can clarify anything.

Thanks very much for a great config file system :)

Cheers,
-- 
Chris Jones
  cm...@te...
   www.tenshu.net

Re: [Configobj-develop] validation question

[David H. <neg...@gm...>]

Well..  it might make more sense to just flatten the hierarchy within the
config, and use a property to achieve the association.  A config or
validation spec doesn't have to _look_ like your data model, it just has to
represent the model.

[layouts]
  [[mydebugginglayout]]
    [[window0]]
      type = Window
      parent =
    [[child1]]
      type = Terminal
      parent = window0
    [[child2]]
      type = VPaned
      parent = window0
    [[child3]]
      type = HPaned
      parent = child2
    [[child4]]
      type = Terminal
      parent = child3
    [[child5]]
      type = Terminal
      parent = child3
    [[child6]]
      type = Terminal
      parent = child2


That lends itself very nicely to a __many__ block in the validation spec.
And all the information necessary to completely recover the full nested
hierarchy is there.  The only thing you'd have to protect against is the
presence in the config data of a bogus node name (i.e. referencing a missing
parent), since the organization of the data itself wouldn't guarantee
validity.


cheers,

-David


On Mon, Feb 1, 2010 at 08:29, Chris Jones <cm...@te...> wrote:

> Hey
>
> I'm using the excellent validation features to convert config files into
> the correct types, and it's working very well so far. I hacked something
> up that generates the configspec on the fly based on my own internal
> tree of default values, which has been a nice timesaver.
>
> However, I'm now trying to extend my application and I'm struggling to
> conceptualise how I'm going to validate the config (and more
> importantly, convert the types automatically).
>
> The problem is that the config section for the new feature is recursive.
> It's intended to describe a particular layout of widgets in my
> application, so the same layout can be recreated when starting the
> application.
> (the application is a tiled terminal emulator,
> http://www.tenshu.net/terminator)
>
> The config structure would be something like:
>
> [layouts]
>  [mydebugginglayout]
>    [window0]
>      type = Window
>      [child1]
>        type = Terminal
>      [child2]
>        type = VPaned
>        [child3]
>          type = HPaned
>            [child4]
>              type = Terminal
>            [child5]
>              type = Terminal
>        [child6]
>          type = Terminal
>
> I'm not super happy about the windowN/childN section names, but storing
> those as lists doesn't seem to fit the configobj style, so I'm expecting
> to autogenerate them.
> Given that this can essentially nest infinitely, how would I write a
> configspec for it?
> Would it make more sense to store the children of each level as a list
> and treat it as a string, then recursively validate each child object?
>
> I'm not sure that any of what I've just written makes sense, let me know
> if I can clarify anything.
>
> Thanks very much for a great config file system :)
>
> Cheers,
> --
> Chris Jones
>  cm...@te...
>   www.tenshu.net
>
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>

Re: [Configobj-develop] validation question

[Michael F. <fuz...@vo...>]

On 01/02/2010 13:29, Chris Jones wrote:
> Hey
>
> I'm using the excellent validation features to convert config files into
> the correct types, and it's working very well so far. I hacked something
> up that generates the configspec on the fly based on my own internal
> tree of default values, which has been a nice timesaver.
>
> However, I'm now trying to extend my application and I'm struggling to
> conceptualise how I'm going to validate the config (and more
> importantly, convert the types automatically).
>
> The problem is that the config section for the new feature is recursive.
> It's intended to describe a particular layout of widgets in my
> application, so the same layout can be recreated when starting the
> application.
> (the application is a tiled terminal emulator,
> http://www.tenshu.net/terminator)
>
> The config structure would be something like:
>
> [layouts]
>    [mydebugginglayout]
>      [window0]
>        type = Window
>        [child1]
>          type = Terminal
>        [child2]
>          type = VPaned
>          [child3]
>            type = HPaned
>              [child4]
>                type = Terminal
>              [child5]
>                type = Terminal
>          [child6]
>            type = Terminal
>
>    


One possibility would be to have each element as a top level item (with 
generated name) that can be validated with a standard configspec. Each 
item could have a list of children (ordered) - specified by name. 
Perhaps something like this:

[layouts]
[[mydebugginglayout]]
[[[window0]]]
type = Window
children = child0, child1, child2
[[[child0]]
...

This would be easier to validate but means your config file doesn't 
reflect the layout structure directly.

Validation doesn't currently support recursive repeated sections, so I 
can't think of an obvious way of doing what you want - other than doing 
the recursion manually validating a section at a time... That probably 
wouldn't be too hard if you prefer that.

Michael



> I'm not super happy about the windowN/childN section names, but storing
> those as lists doesn't seem to fit the configobj style, so I'm expecting
> to autogenerate them.
> Given that this can essentially nest infinitely, how would I write a
> configspec for it?
> Would it make more sense to store the children of each level as a list
> and treat it as a string, then recursively validate each child object?
>
> I'm not sure that any of what I've just written makes sense, let me know
> if I can clarify anything.
>
> Thanks very much for a great config file system :)
>
> Cheers,
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.