config4gnu-developer

Re: [Config4gnu-developer] real "flatfile" parser/unparser

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

Greg-

The files have been committed. Here is some feedback :)

1. The following:
     else {
          die $line;
     }
   has to go. If a line does not match one of the patterns it should somehow
be preserved in the XML file. Otherwise, when the file is rewritten, that
data (valid or not) is lost. Perhaps you could use a comment tag, since you
preserve the '#' in comments.

2. Can we put all the parameters into one big section? Since all the data in
a "flatfile" is for one purpose, I think it makes sense to group it
together. Instead of incrementing section numbers we could increment
parameter numbers. Or the parameters could all have the same name, since
they all are used the same way.

3. I already made a slight change to the "unparser" to allow this. Instead
of

  $param = $section->getElementsByTagName('parameter')->item(0)

it is changed to

  foreach my $param ($section->getElementsByTagName('parameter'))

4. This hasn't been done for the other parsers, but I think it'd be nice to
have an area at the top of each parser to explain the file format that it
works with. Something like

  Handles files that contain one or more values. Each value exists on a line
by itself. Blank lines and lines beginning with '#' are ignored by the
application.

Thanks for contributing and I hope to hear more from you!

Jason Long

Re: [Config4gnu-developer] real "flatfile" parser/unparser

[Gregory R. T. S. <gs...@ri...>]

> Greg-
>
> The files have been committed. Here is some feedback :)

Thanks!  I appreciate the feedback.

> 1. The following:
>      else {
>           die $line;
>      }
>    has to go. If a line does not match one of the patterns it should somehow
> be preserved in the XML file. Otherwise, when the file is rewritten, that
> data (valid or not) is lost. Perhaps you could use a comment tag, since you
> preserve the '#' in comments.

Agreed.  Perhaps we could put it in a comment and add a comment on the
line before indicating that the parser didn't know what to do with this
line?

> 2. Can we put all the parameters into one big section? Since all the data in
> a "flatfile" is for one purpose, I think it makes sense to group it
> together. Instead of incrementing section numbers we could increment
> parameter numbers. Or the parameters could all have the same name, since
> they all are used the same way.

Yeah, that makes more sense, but I wasn't sure if the core layer had
support for this.  Having the parameters all have the same name makes the
most sense to me.

> 4. This hasn't been done for the other parsers, but I think it'd be nice to
> have an area at the top of each parser to explain the file format that it
> works with. Something like
>
>   Handles files that contain one or more values. Each value exists on a line
> by itself. Blank lines and lines beginning with '#' are ignored by the
> application.

This is a good idea, and I'd be happy to do it.  Should I continue to
email patches to the list or should I commit them in CVS?

> Thanks for contributing and I hope to hear more from you!

Thanks!

> Jason Long

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"