[Config4gnu-developer] forms and class definition files

[Jason L. <jl...@me...>]

Config4GNU developers,

I've been at work trying to get the "forms" implemented. I had been working
on "wizards" but decided that "forms" should probably come first... I think
they're less complicated.

Forms are listed by node type. E.g. there might be a node type called "user"
and when that node type is selected in the front-end the program can display
a form for entering "user" properties.

But in order to get the forms available, we need to know where to specify
them. In other words, given a particular node, how can I know what forms to
display. ... If I select a node named "public" of type "section" within a
node of type "inifile", I want to see a form for editing properties of a
Samba share. But how is Config4GNU going to know that this is a Samba share?

Somehow we need a way to map those "section" nodes in the inifile to nodes
of type "sambashare" or similar. Once the nodes are of type "sambashare" it
is a simple matter to associate the forms for Samba shares with those nodes.

Here are a few approaches I've thought of to this problem:

1. Make the parsers smarter, or make additional parsers specific to the
applications. This seems to contradict our idea to make generic, flexible
parsers.

2. Specify some sort of transformation between the output of the parsers and
importation into the configuration tree. A language such as XSLT is powerful
enough but then we need to specify a transformation for both ways (i.e. the
data has to go back to the parser in the original form).

3. This third idea I came up with specific to Samba but it may work for the
general case. Have the <samba> class specify what child nodes to use, and
have Config4GNU match them based on requirements. E.g. the <samba> class
specifies that possible children are <sambaglobal>, <sambahomes>,
<sambaprinters>, <sambaprintershare>, <sambafileshare>. Then, the class
files for each of these child nodes specify requirements...
  e.g. <sambaglobal> specifies that the name of the section must be "global"
       <sambahomes> specifies that the name of the section must be "homes"
       <sambaprintershare> specifis that the property named "printable" (or
synonyms) must have the value "yes" (or synonyms).

What do you think? I think approach 3 is preferable because it seems like it
is the simplest. I don't think we want third-parties to have to write their
own parsers or write complicated XSLT stylesheets. (Although they can always
use the generic class for their fileformat, e.g. inifile.)

If you agree that option 3 is best, what kind of syntax should be used to
express these requirements? While we're at it, what syntax can be used to
express property defaults, descriptions, and data types?

Here's a sketch...

<class name="sambafileshare">
  <extends class="inisection"/>
  <required-property>
    <name>path</name>
  </required-property>
  <property-definition>
    <name>path</name>
    <datatype>path</datatype>
    <description>....</description>
  </property-definition>
  <property-definition>
    <name>writeable</name>
    <datatype>boolean</datatype>
    <description>...</description>
    <default-value>no</default-value>
  </property-definition>
</class>

Jason Long