On Friday 01 February 2008 7:28 am, Ed Leafe wrote: > 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 >
Thanks for the tip. I have some further comments but they will have to wait, work beckons. -- Adrian Klaver [EMAIL PROTECTED] _______________________________________________ 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]
