[Pythoncard-users] Re: any feature requests?

[PeterAndBrian <pe...@pe...>]

At 12:17 PM 9/12/2001 -0700, Andy Todd wrote:
>In addition, the format and content of the actual application data is in
>the control of the developer and we should not constrain that in any
>way. I think we should support multiple back ends, and to that end we
>already have applications that support ZODB and MySQL. I'm currently
>working on a csv module and will also look at other RDBMS (Oracle and
>PostgreSQL are on my list). The developer of a PythonCard application
>should have the ability to choose where to store their data rather than
>us forcing a solution on them. Eventually we would want to support some
>kind of agnostic persistence layer (much like the approach AnyGui has
>taken to windowing toolkits) but we should wait until the framework and
>API have been worked out a bit more thoroughly.


Andy - I agree, we don't want to constrain anyone from using any data 
storage they see fit.  HyperCard did not prevent users from calling outside 
storage when needed.  But it did provide a built in, automatic, and 
wonderfully simple storage mechanism that met most peoples needs, most of 
the time.

At Wed, 12 Sep 2001 09:56:08 -0700, Kevin Altis wrote:
>I don't think we have a best candidate. What we discussed when the list
>started was a generic card or record class that would support a variety of
>backend data stores (repositories). The textIndexer sample uses ZODB. The
>addresses sample uses a list of dictionaries.


We will certainly need some mechanism, addressable by dot notation and 
immediately usable right out of the box, without any additional software 
requirements beyond Python and the PythonCard framework itself.  I'm not 
competent to code it (at this point), but here's my picture of implicit 
persistence:

Shelve is a memory friendly dictionary-like object that lives in a file, 
whose members can be any type of object.  So one simple approach to 
implicit persistence is for the Card class to bind selected properties of 
each Widget to a dictionary for that card, keyed by object name.  Store 
that dictionary in the Shelve object, keyed to the cardID.  Deal with card 
loading and unloading in the event dispatcher when generating openCard and 
closeCard messages.   Set the widget properties on load and get them on 
unload and the user gets free data persistence.  Make the card level 
dictionary available as "thisCard" via dot notation and you also have a 
dandy place for PythonCard developers to store arbitrary data structures 
they want persisted on a per card basis.

One of the joys of HyperCard was that it opened the door to countless 
neophyte programmers. Sure - it led to lots of "bad" programs in the 
traditional sense.  People abused the Card level storage mechanism in a 
variety of ways and stretched that environment to absurd levels.  But 
everyone starts out writing bad code.  HyperCard's highest achievement was 
allowing those newbies to get started.  I think PythonCard should keep them 
in mind first, without compromising the power or versatility available to 
experienced coders.

Peter