Re: meta language to define forms
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Fri, 28 Mar 2014 14:57:11 +1100, Chris Angelico wrote: On Fri, Mar 28, 2014 at 2:44 PM, Rustom Mody rustompm...@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 Not to mention that the windows registry is a Single Point of failure. if it gets corrupt (by 1 minor program crashing whilst writing to it)the chances are your OS is broken to the point of being unfixable. at least with the Linux system ( the multiple config files of windows 3 earlier) it can normaly be fixed with a simple text editor. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Friday, March 28, 2014 2:34:07 PM UTC+5:30, alister wrote: On Fri, 28 Mar 2014 14:57:11 +1100, Chris Angelico wrote: 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 Not to mention that the windows registry is a Single Point of failure. if it gets corrupt (by 1 minor program crashing whilst writing to it)the chances are your OS is broken to the point of being unfixable. at least with the Linux system ( the multiple config files of windows 3 earlier) it can normaly be fixed with a simple text editor. This sure used to be true in the windows 95-98 era. I dont believe its been this way for more than a decade. XP onwards there's enough redundancy+fallback+checkpointing so that we rarely really hear of this any more [But Im not a windows guy :-)] On the other hand in linux I find that when something is upgraded and needs to upgrade *its own* config files in /etc it can often have trouble. I trace this to the fact that what is needed is mostly a simple key-value store holding some config parameters. What is stored is usually a general script. As a result http://www.w3.org/2001/tag/doc/leastPower.html kicks in. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
Rustom Mody rustompm...@gmail.com: On the other hand in linux I find that when something is upgraded and needs to upgrade *its own* config files in /etc it can often have trouble. Linux (service) configuration has given me a lot of grief as well. However, I don't thing anything should need to upgrade config files. The packaging tools leave the old config file in place, which is the right thing. The service had better support the old config file format with no interpretation changes. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Friday, March 28, 2014 5:44:48 PM UTC+5:30, Marko Rauhamaa wrote: Rustom Mody wrote: On the other hand in linux I find that when something is upgraded and needs to upgrade *its own* config files in /etc it can often have trouble. Linux (service) configuration has given me a lot of grief as well. However, I don't thing anything should need to upgrade config files. Strange thing to say. There may be new config options. The defaults may be altered with good reason. This needs a new file OTOH the user may have his own old altered defaults. So integrating the two is not exactly an easy problem. And what apt does in this case is to drop you into some half-assed interactive (so-called) mode saying some file has changed -- Do you want to keep old, choose new, drop into a shell, or some other half-baked options The packaging tools leave the old config file in place, which is the right thing. They dont exactly do that -- see above -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On 3/27/2014 4:56 PM, Sells, Fred wrote: 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've run into a similar problem when building a framework for programming by speech and web application development. Although, my goals were different. I want to something you can create with speech recognition without too much of a vocal load or requiring extensive/specialized editor changes. One could say I was trying to make it possible to develop web apps in Microsoft Word. :-) The first attempt was a bracketed notation that was in effect a very high level domain specific notation. The next attempt is trying to eliminate the use of bracketing notation to specify scope and said use indentation. Like you, the environment consists of little bits of Python that takes what you want in the form/user interface and generates the HTML and JavaScript for presentation in action. To use your example, my notation would look something like this : Form uses section_title; Enter Patient Vital Signs uses number_question; 3, Enter pulse rate : drop_down_list uses title; Enter current status uses choices; 1, alive and kicking uses choices; 2, comatose uses choices; 3, there's another dead Bishop on the landing The: names refer to the methods that generate the code using the arguments provided by the statements within the: name definition. as refine what is your trying to do, you can make the: names more and more meta-and less and less implementation details. For example, one of the experiences that told me the bracketed notation was not going to fly was when I created a storefront for telescope shop. I created notation that expressed the work of the store not the display of the store information. Obviously the output of the notation was the display data but it operated in a way that the storekeeper understood and could take care of himself which was impossible with ordinary HTML and completely impossible if you added something like bootstrap. And before somebody kicks up a fuss About the notation, let me say that this was aimed at disabled developers who cannot type anymore or who want to listen because they cannot see. What I have created is far more productive and speakable than any of the other systems out there. --- eric -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
Rustom Mody rustompm...@gmail.com: On Friday, March 28, 2014 5:44:48 PM UTC+5:30, Marko Rauhamaa wrote: I don't thing anything should need to upgrade config files. Strange thing to say. There may be new config options. The missing options should default to the old behavior. The defaults may be altered with good reason. Occasionally, but the reason had better be *really* good. It is like changing a programming API. You live with your bad decisions. And what apt does in this case is to drop you into some half-assed interactive (so-called) mode saying some file has changed -- Do you want to keep old, choose new, drop into a shell, or some other half-baked options RPM won't overwrite modified config files but just places the new version there next to the old one under a different name (and gives a warning). RPM isn't perfect, but that is the sane thing to do. Marko -- https://mail.python.org/mailman/listinfo/python-list
meta language to define forms
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On 3/27/2014 4:56 PM, Sells, Fred wrote: 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. Have you searched the python-list archives? PyPI? or the web? There was a thread on this topic perhaps a month ago but I barely followed it. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Fri, Mar 28, 2014 at 7:56 AM, Sells, Fred
fred.se...@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
Re: meta language to define forms
In article mailman.8653.1395975737.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Fri, Mar 28, 2014 at 7:56 AM, Sells, Fred fred.se...@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. -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Fri, Mar 28, 2014 at 2:13 PM, Roy Smith r...@panix.com wrote: In article mailman.8653.1395975737.18130.python-l...@python.org, Chris Angelico ros...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
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] -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
On Fri, Mar 28, 2014 at 2:44 PM, Rustom Mody rustompm...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: meta language to define forms
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 -- https://mail.python.org/mailman/listinfo/python-list
