"Chris Angelico" <ros...@gmail.com> wrote in message
news:CAPTjJmokZUHta7Y3x_=6eujkpv2td2iaqro1su7nulo+gfz...@mail.gmail.com...
> On Thu, Jan 23, 2014 at 8:16 AM, Asaf Las <roeg...@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
--
https://mail.python.org/mailman/listinfo/python-list
