RE: [Pythoncard-users] Script Encapsulation

[Kevin A. <al...@se...>]

> From: Andy Todd
>
> There was discussion a few weeks (months?) ago on the list of storing
> the code and resource description in an XML format but nothing has come
> of that. There is no reason we can't do it, just that no one has got
> round to attempting an implementation yet. For the reason above, I'm not
> sure this has legs either but I am happy to stand corrected.

I have to interject my standard XML mantra here which is that "XML should be
created and read by programs, but never seen or edited by humans". As long
as it is likely that we will have to hand edit any resources or source code
I will resist putting them into XML. You'll thank me later :) Among other
things, you can't process invalid XML and so you need an XML editor that can
identify the specific problem line(s), while our current dictionary/list
files can be checked by any standard Python-aware editor or IDE to make sure
they are valid. They are also much easier on the eyes than XML. I guess
nobody remembers that HTML was never intended to be seen or edited by humans
either, but gee look at the mess we got ourselves into.

> My personal vote would be to maintain the python module format for the
> 'program' portion of each stack because then we are still dealing with
> 'pure' Python and all of the benefits that brings. For instance, it is
> possible currently to import and test a PythonCard class without running
> it in the framework as, to Python, each module just contains a class.

Excellent points!

This is also a good time to point out that all the code doesn't have to go
into a single module file. The only code that has to be in the background
class are the handlers for the widget events and even those can just be the
def and then a line that calls a method in a different function or class in
a completely different module file. However, if you need to reference the
background self... it might be more convenient to stick the code in the
background.

Some of the samples use multiple modules and some of the samples use classes
other than the main background. Most of the time when I put "everything" in
the subclass of Background, I was coding rapidly and got a bit lazy. I have
spent very little time refactoring the various samples.

ka