On Feb 1, 2008, at 8:59 AM, Adrian Klaver wrote:
> A couple of points:
> Changes made to a cdxml file outside of the ClassDesigner seem to get
> overwritten.
Depends on the change. If there is something that is not being
properly persisted, then that is a bug and should be reported. This
has nothing to do with XML, and it is wrong to place the blame for
this on XML. It is simply a matter of the Class Designer not being
tested and debugged as well as it needs to be.
> Getting the coding/escaping right for XML is finicky and error prone.
It is plain text. You declare the encoding in the header, and the
rest is handled by the tools for parsing XML. It is no more difficult
than encoding in a .py file.
Python has its own escaping issues, especially with pathing on Windows.
> I am progressing to that point, but in the absence of documentation
> of how the
> various parts of Dabo work together the ClassDesigner is the best
> tool to
> learn Dabo.
When you save a design into separate .cdxml and .py files, you get a
wonderful visual description of the separation of the GUI structure
(.cdxml) and action (.py). Constructing the GUI widgets is not
interesting; it is a necessary part of creating a desktop app. What
those widgets do is the interesting part.
> I realize I am fighting an uphill battle in regards to XML, one I
> waging on
> multiple fronts. I for one think it sucks as a data storage tool.
> For similar
> purposes I find YAML(http://pyyaml.org/) to be much easier to work
> with and
> understand. Just my 2 cents.
I would rather defend the choice of a nearly-universal standard such
as XML to the occasional naysayer such as yourself than have to defend
the choice of a relatively unknown and obscure format to the vast
majority of users.
> My goal at some point in the near future. The issue such as it is,
> is that the
> entry point for people new to Dabo will be ClassDesigner and they
> will start
> looking at the cdxml files to see how things are done. Seeing Python
> code
> would be more helpful in seeing how things work.
Here I strongly disagree. The .cdxml is very helpful in revealing the
structure; try creating a complex layout using nested sizers, paged
controls and grids, and then look at the resulting .cdxml file. You'll
see an exact mirror of the form's structure. Now imagine the Python
code necessary to create the same form: there would be no visual clue
as to what is nested within what.
> At some point the XML in the
> cdxml is converted back to Python to generate a form. If there was
> way to
> dump that information (however inelegant) back to a file it would be
> very
> helpful.
Of course there is a way; whether it is helpful or not is debatable.
The reason is that in order to create generic translations, the code
that is produced, while perfectly functional, is hardly as tight,
efficient or attractive as what a human could write.
To see the output, open dabo/lib/DesignerXmlConverter.py and
uncomment line #68. The next time you run a .cdxml structure, a file
in the directory you are running from will be created; its name will
be "CLASSTEXT.py". You can then read that file to see just what is
being created. Be forewarned, though: it is not an example of how
anyone would write Dabo UI code.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
