Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69243 > unrolled thread

Re: meta language to define forms

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: meta language to define forms Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:02 +1100
    Re: meta language to define forms Roy Smith <roy@panix.com> - 2014-03-27 23:13 -0400
      Re: meta language to define forms Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:30 +1100
      Re: meta language to define forms Rustom Mody <rustompmody@gmail.com> - 2014-03-27 20:44 -0700
        Re: meta language to define forms Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:57 +1100
          Re: meta language to define forms Rustom Mody <rustompmody@gmail.com> - 2014-03-27 21:19 -0700

#69243 — Re: meta language to define forms

On Fri, Mar 28, 2014 at 7:56 AM, Sells, Fred
<fred.sells@adventistcare.org> wrote:
> I don't have a lot of time or management support to do something elegant like XML and then parse it, I'm thinking more like
>
> Class  FyFormNumber001(GeneralForm):
>         Section1 = Section(title="Enter Patient Vital Signs")
>                 Question1 = NumberQuestion(title="Enter pulse rate", format="%d3")
>                 Question2 = Dropdown(title="Enter current status")
>                 Question2.choices = [ (1, "Alive and Kicking"), (2, "Comatose"), (3, "Dead"), ...]

Rule of Python: XML is not the answer. XML is the question, and "NO!"
is the answer :)

Your syntax there looks reasonable already. I'd recommend you make it
a flat data file, though, don't try to make it a programming language
- unless you actively need it to be one. Here are a couple of ways you
could format this. Any would be fairly easy to code a parser for.

(I'm guessing your format there should probably be "%3d", if you mean
printf notation. But I'll keep your "%d3" example in the below.)

1) Using indentation for nesting, and a "command, space, args" model:

GeneralForm FyFormNumber001
        Section "Enter Patient Vital Signs"
                NumberQuestion "Enter pulse rate" format="%d3"
                Dropdown "Enter current status"
                        Choice 1 "Alive and Kicking"
                        Choice 2 "Comatose"
                        Choice 3 "Dead"
                        ...

This would be parsed with an algorithm like this:
* Maintain an indentation stack, which starts with a top level entry.
* Read one line. Parse it into three parts: leading indentation, command, args.
* Remove from the indentation stack everything equal to or greater
than this line's indent.
* Send the command to the last entry on your indentation stack, with its args.
* Capture the result of that command and put it on the indentation stack.
* Iterate until end of file.

You'd then have a top-level object that understands a "GeneralForm"
command and returns a form object; the form object understands the
"Section" command and returns a section object; the "Dropdown" object
understands "Choice"; and so on.


2) Rendering the whole thing as JSON:

{"type": "GeneralForm", "FormName": "FyFormNumber001", "children": [
        {"type":"Section", "Title": "Enter Patient Vital Signs", "children": [
                {"type": "NumberQuestion", "title":"Enter pulse rate",
"format":"%d3"},
                {"type": "Dropdown", "title":"Enter current status",
"children": [
                        {"type":"Choice", "value":1, "name":"Alive and
Kicking"},
                        {"type":"Choice", "value":2, "name":"Comatose"},
                        {"type":"Choice", "value":3, "name":"Dead"},
                        ...
                ]}
        ]}
]}

This would be parsed by first converting the JSON into a tree of dicts
and lists, and then at each step, checking the type, and processing
its children. The bulk of the work could be done generically, and it's
easy to add attributes to anything. The cost, though, is that you need
to be a bit verbose about the common attributes.


3) Actual Python code:

FyFormNumber001 = GeneralForm(
        Sections = [Section("Enter Patient Vital Signs", Questions=[
                NumberQuestion("Enter pulse rate", format="%d3"),
                Dropdown("Enter current status",
                        choices=[ (1, "Alive and Kicking"), (2,
"Comatose"), (3, "Dead"), ...]
                ),
        ]),
])

This would be parsed by creating functions or classes named
GeneralForm, Section, NumberQuestion, etc, and having them handle
positional arguments for the obvious things, and keyword args for the
less obvious. (I may have misjudged which is which, but you should
make a design decision about that.) I've used keyword args for
everything that's a list, but that could be done differently if you
choose.


4) Actual Pike code.

This came up in the thread Terry's referring to. Its primary advantage
was that it *already existed* (we were talking about GTK2), where all
the above options do require code. It would look something like this:

object FyFormNumber001=GeneralForm()
        ->add(Section("Enter Patient Vital Signs")
                ->add(NumberQuestion("Enter pulse rate", "%d3"))
                ->add(Dropdown("Enter current status")
                        ->add_choice(1, "Alive and Kicking")
                        ->add_choice(2, "Comatose")
                        ->add_choice(3, "Dead")
                        ...
                )
        )
;

I don't recommend this above the options listed above; but I'd say
it's at least 95% as good as the others, and if you find a way to get
something that looks like this with practically zero effort, I would
strongly advise going with it. (Another advantage of the Pike GTK2
system is that you often want to manipulate the objects post-creation
and pre-insertion into the tree. I don't think you need that
flexibility here, so again, this one is just for comparison.)

If you can, try to go for the first option. It's clean, and it's not
terribly hard to parse. Failing that, the third option isn't too bad,
but I'd advise against going with JSON; one misplaced comma or bracket
and you have a tough debugging problem to solve. You might get that
problem with the Python-code version too, but you have a bit of a
better chance at a readable traceback there.

ChrisA

[toc] | [next] | [standalone]

#69246

In article <mailman.8653.1395975737.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Mar 28, 2014 at 7:56 AM, Sells, Fred
> <fred.sells@adventistcare.org> wrote:
> > I don't have a lot of time or management support to do something elegant 
> > like XML and then parse it, I'm thinking more like
> >
> > Class  FyFormNumber001(GeneralForm):
> >         Section1 = Section(title="Enter Patient Vital Signs")
> >                 Question1 = NumberQuestion(title="Enter pulse rate", 
> >                 format="%d3")
> >                 Question2 = Dropdown(title="Enter current status")
> >                 Question2.choices = [ (1, "Alive and Kicking"), (2, 
> >                 "Comatose"), (3, "Dead"), ...]
> 
> Rule of Python: XML is not the answer. XML is the question, and "NO!"
> is the answer :)

The nice thing about that rule is that it ports easily to so many other 
programming languages.  Except possibly Java.  Java and XML seem to be 
made for each other.
 
> Your syntax there looks reasonable already. I'd recommend you make it
> a flat data file, though, don't try to make it a programming language
> - unless you actively need it to be one. Here are a couple of ways you
> could format this. Any would be fairly easy to code a parser for.

My first impression here is that YAML might work here.

[toc] | [prev] | [next] | [standalone]

#69248

On Fri, Mar 28, 2014 at 2:13 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.8653.1395975737.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>> Rule of Python: XML is not the answer. XML is the question, and "NO!"
>> is the answer :)
>
> The nice thing about that rule is that it ports easily to so many other
> programming languages.  Except possibly Java.  Java and XML seem to be
> made for each other.

The only times I have *ever* used XML, in my whole life, were when I
needed to communicate with some other end that stipulated XML. (Most
commonly XML payload in HTTP requests and responses, eg SOAP.) In most
of those cases, some simpler structure would have sufficed; and in a
number of them, XML is simply wrong for the job.

>> Your syntax there looks reasonable already. I'd recommend you make it
>> a flat data file, though, don't try to make it a programming language
>> - unless you actively need it to be one. Here are a couple of ways you
>> could format this. Any would be fairly easy to code a parser for.
>
> My first impression here is that YAML might work here.

Good point. Add it as a fifth option!

That section was already turning into a cardinal's weaponry statement.
I said "a couple" and ended up with four... now five. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69249

On Friday, March 28, 2014 8:43:21 AM UTC+5:30, Roy Smith wrote:
>  Chris Angelico wrote:
> > Your syntax there looks reasonable already. I'd recommend you make it
> > a flat data file, though, don't try to make it a programming language
> > - unless you actively need it to be one. Here are a couple of ways you
> > could format this. Any would be fairly easy to code a parser for.

> My first impression here is that YAML might work here.

Was going to say yaml would be my first choice.

The only question here is whether to use the full-featured load or safe_load
which only allows builtin types.

In general load allowing calling of arbitrary code is a gaping security hole.
Here it may be the best choice... dunno

Personally I dont like mixing code and data.
Yeah lisp is fun and all that but when it starts getting at all serious
its a bloody mess.

[BTW I consider the windows registry cleaner than the linux /etc for 
the same reason]

[toc] | [prev] | [next] | [standalone]

#69250

On Fri, Mar 28, 2014 at 2:44 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> [BTW I consider the windows registry cleaner than the linux /etc for
> the same reason]

And if I felt like trolling, I'd point out that there are a lot more
search engine hits for "windows registry cleaner" than "linux etc
cleaner". :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69251

On Friday, March 28, 2014 9:27:11 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Mar 28, 2014 at 2:44 PM, Rustom Mody  wrote:
> > [BTW I consider the windows registry cleaner than the linux /etc for
> > the same reason]

> And if I felt like trolling, I'd point out that there are a lot more
> search engine hits for "windows registry cleaner" than "linux etc
> cleaner". :)

Probably(!) follows from the fact that one is more possible than the other. 
Because of http://www.w3.org/2001/tag/doc/leastPower.html

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web