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


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

meta language to define forms

Started by"Sells, Fred" <fred.sells@adventistcare.org>
First post2014-03-27 20:56 +0000
Last post2014-03-28 16:37 +1000
Articles 2 — 2 participants

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


Contents

  meta language to define forms "Sells, Fred" <fred.sells@adventistcare.org> - 2014-03-27 20:56 +0000
    Re: meta language to define forms alex23 <wuwei23@gmail.com> - 2014-03-28 16:37 +1000

#69218 — meta language to define forms

From"Sells, Fred" <fred.sells@adventistcare.org>
Date2014-03-27 20:56 +0000
Subjectmeta language to define forms
Message-ID<mailman.8632.1395953860.18130.python-list@python.org>
I'm trying to use python classes and members to define complex data entry forms as a meta language

The idea is to use a nice clean syntax like Python to define form content, then render it as HTML but only as a review tool for users,  The actual rendering would go into a database to let a vendor's tool generate the form in a totally non-standard syntax that's really clunky.

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"), ...]


Of course this is not quite legal python and I have a lot of flexibility in my "meta" language.  The basic model is that a single file would define a form which would have one or more sections,  each section would have one or more questions of various types (i.e. checkbox, radio button, text, etc).  Sections cannot be nested.

I don't have to have a perfect layout, just close enough to get the end users to focus on what they are asking for before we generate the actual code.  I tried an HTML WYSIWYG editor but that was too slow and I lost information that I need to retain when the actual form is generated.

The biggest problem (to me) is that I have to maintain the order; i.e. the order in which they are coded should be the order in which they are displayed.

I'm looking to do about 200 forms, so it is reasonable to invest some time up front to make the process work; meanwhile management wants results yesterday, so I have a trade-off to make.

Is there anything out there that would be close or do you have any suggestions.

Thanks.

[toc] | [next] | [standalone]


#69253

Fromalex23 <wuwei23@gmail.com>
Date2014-03-28 16:37 +1000
Message-ID<lh35b0$opb$1@dont-email.me>
In reply to#69218
On 28/03/2014 6:56 AM, Sells, Fred wrote:
> The idea is to use a nice clean syntax like Python to define form content, then render it as HTML but only as a review tool for users,  The actual rendering would go into a database to let a vendor's tool generate the form in a totally non-standard syntax that's really clunky.
>
> 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"), ...]
>
> Is there anything out there that would be close or do you have any suggestions.

Are you familiar with z3c.form?

https://pypi.python.org/pypi/z3c.form

Given that it's part of the Zope web framework, it's fairly heavily 
geared towards working with HTTP requests, but it's quite possible to 
only use the parts that want. For your requirement, you could probably 
get a long way with using zope.schema for defining the forms, and then 
customising some of the templates to render them appropriately. The 
provided widgets are easily extensible, so adding support for the vendor 
form syntax - possibly as additional templates alongside the HTML ones - 
should be doable.

[toc] | [prev] | [standalone]


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


csiph-web