Python declarative

[Frank Millman]

"Chris Angelico" <rosuav at gmail.com> wrote in message 
news:CAPTjJmokZUHta7Y3x_=6eUjKpv2Td2iaqro1su7NuLo+gfzwag at mail.gmail.com...
> On Thu, Jan 23, 2014 at 8:16 AM, Asaf Las <roegltd at gmail.com> wrote:
>> i am novice in python, but let me suggest you something:
>> it would be beneficial to use json text file to specify
>> your gui so composite data structure can be created using
>> json and then your program can construct window giving
>> its content will be based on simple text file?
>> You can add every parameter to json encoded window system
>> once your window construction will be using as interpreter
>> for that. JSON is very structured and quite presentable for
>> such kind of things.
>>
>> What Gurus do think about this suggestion?
>
> JSON is better than XML for that, but in my opinion, both are
> unnecessary. Python code is easy to edit. (See [1] for more on Python
> and XML.) When you're writing compiled code, it makes good sense to
> drop out of code and use a simple text file when you can; but when
> your code *is* a simple text file, why go to the effort of making a
> JSON-based window builder? (Unless you already have one. GladeXML may
> well be exactly what you want, in which case, go ahead and use it. But
> personally, I don't.) JSON is a fantastic format for transmitting
> complex objects around the internet; it's compact (unlike XML),
> readable in many languages (like XML), easily readable by humans
> (UNLIKE XML!), and can represent all the most common data structures
> (subtly, XML can't technically do this). It's superb at what it
> does... but it doesn't do Python GUIs. For those, use Python itself.
>

I find that I am using JSON and XML more and more in my project, so I 
thought I would explain what I am doing to see if others think this is an 
acceptable approach or if I have taken a wrong turn.

I have various data structures, some simple, some more complex, of which I 
have many instances. I want to serialise and store them in a database. This 
has two benefits. Firstly, I just have to write one piece of python code 
that interprets and deals with each structure, so it avoids duplicate code. 
Secondly, I can design a gui that exposes the structures to non-programmers, 
giving them the ability to modify them or create new ones. Simple structures 
can be expressed in JSON. I use XML to represent the more complex ones.

I will give two examples, one simple and one complex.

I store database metadata in the database itself. I have a table that 
defines each table in the database, and I have a table that defines each 
column. Column definitions include information such as data type, allow 
null, allow amend, maximum length, etc. Some columns require that the value 
is constrained to a subset of allowable values (e.g. 'title' must be one of 
'Mr', 'Mrs', etc.). I know that this can be handled by a 'check' constraint, 
but I have added some additional features which can't be handled by that. So 
I have a column in my column-definition table called 'choices', which 
contains a JSON'd list of allowable choices. It is actually more complex 
than that, but this will suffice for a simple example.

For my more complex example, I should explain that my project involves 
writing a generalised business/accounting system. Anyone who has worked on 
these knows that you quickly end up with hundreds of database tables storing 
business data, and hundreds of forms allowing users to CRUD the data 
(create/read/update/delete). Each form is unique, and yet they all share a 
lot of common characteristics. I have abstracted the contents of a form 
sufficiently that I can represent at least 90% of it in XML. This is not 
just the gui, but all the other elements - the tables required, any input 
parameters, any output parameters, creating any variables to be used while 
entering the form, any business logic to be applied at each point, etc. Each 
form definition is stored as gzip'd XML in a database, and linked to the 
menu system. There is just one python program that responds to the selection 
of a menu option, retrieves the form from the database, unpacks it and runs 
it.

Incidentally, I would take issue with the comment that 'JSON is easily 
readable by humans (UNLIKE XML)'. Here is a more complete example of my 
'choices' definition.

[true, true, [["admin", "System administrator", [], []], ["ind", 
"Individual", [["first_name", true], ["surname", true]], [["first_name", " 
"], ["surname", ""]]], ["comp", "Company", [["comp_name", true], ["reg_no", 
true], ["vat_no", false]], [["comp_name", ""]]]]]

You can read it, but what does it mean?

This is what it would look like if I stored it in XML -

<choices use_subtypes="true" use_displaynames="true">
  <choice code="admin" descr="System administrator">
    <subtype_columns/>
    <displaynames/>
  </choice>
  <choice code="ind" descr="Individual">
    <subtype_columns>
      <subtype_column col_name="first_name" required="true"/>
      <subtype_column col_name="surname" required="true"/>
    </subtype_columns>
    <displaynames>
      <displayname col_name="first_name" separator=" "/>
      <displayname col_name="surname" separator=""/>
    </displaynames>
  </choice>
  <choice code="comp" descr="Company">
    <subtype_columns>
      <subtype_column col_name="comp_name" required="true"/>
      <subtype_column col_name="reg_no" required="true"/>
      <subtype_column col_name="vat_no" required="false"/>
    </subtype_columns>
    <displaynames>
      <displayname col_name="comp_name" separator=""/>
    </displaynames>
  </choice>
</choices>

More verbose - sure. Less human-readable - I don't think so.

Also, intuitively one would think it would take much longer to process the 
XML version compared with the JSON version. I have not done any benchmarks, 
but I use lxml, and I am astonished at the speed. Admittedly a typical 
form-processor spends most of its time waiting for user input. Even so, for 
my purposes, I have never felt the slightest slowdown caused by XML.

Comments welcome.

Frank Millman