[Pythoncard-users] design proposal

[Rowland S. <ro...@we...>]

Here's a design proposal for the next iteration of PythonCard.

I've been working on a design for PythonCard that is a refinement of the
current design with the following changes:

HyperCard specific classes/methods have been renamed or removed.  Most 
of the HyperCard-like functionality was never implemented, and I think 
that the names Stack/Background/Card bring a lot of baggage to the table 
that is distracting at this stage in the game.  We have to build a core 
for PythonCard that allows us to build interesting applications, and 
lets us extend the core to include the things we like about HyperCard: 
automatic persistence, cards, backgrounds, etc.

This design makes practically everything a scriptable component: 
Application, Window, View, Widget - they are all components - I think 
this will pay off in the future, even though I don't have good examples 
for why an Application should be a Component, etc.

Meta-Model

With slight changes to spec.py, which is basically a meta-model for
PythonCard components, we can fully document the interfaces that a 
Script can support for a particular component.

The script for a component is totally dynamic, so you could change any
component's script at runtime.

We can build a complex component, and distribute it with it's spec 
entry, and anyone can just drop it in to their PythonCard environment 
and use it, including visual programming tools that support the 
meta-model, like the visual environment we want to build for PythonCard.

So, basically, an IDE can look at a component's meta-model entry, and 
build a script editor for that component that shows the events and the 
methods that scripts for the component can support.

Custom event classes can be defined and added to the environment in 
support of future components.

There are two user programming models - Scripts and Handlers.

Script Objects

Users familiar with OO can program directly with Script objects.  By 
looking at the events a component supports, you can define a subclass of 
script, implement the appropriate methods, and set an instance of the 
script on the desired component.  In addition, a resource file can 
contain an entry for a component that specifies the name of the Script 
class that should be instantiated and bound to the component at runtime.

Handler Objects

The handler based model will look pretty much like it does now.  There 
might be some slight changes, but it basically looks like it does now. 
Handlers  are implemented on top of Scripts.  Handlers hide Scripts from 
the user.  Handlers may be specified in a resource file and bound just 
as they are today.

Component Extensibility

Here's an over-simplified example:

Someone could build a Calendar component that uses our Button widgets,
TextFields, BitMaps, etc.  The Calendar could support custom Events like
CalendarEntryCreatedEvent, CalendarEntryDeletedEvent, etc.  These events
would map to the method names calendarEntryCreated( aEvent ) and
calendarEntryDeleted( aEvent ).

Anyone could drop the Calendar component into their environment, 
construct an instance, set the Script of the Calendar component to a 
user-defined script that handles calendarEntryCreated() and 
calendarEntryDeleted().

The script will be called when ever someone uses the Calendar 
component's gui to add an entry to a day or delete an entry from a day. 
  The script could manage the persistence of the entries, or pass them 
to some scheduling system, etc.

-

A design document that contains descriptions of the classes discussed 
above as well as several UML diagrams can be found at:

http://pythoncard.sourceforge.net/newdesign/design.0.0.3/design.html


As soon as I design the event dispatch mechanism i can prototype both
models programming models.  We'll simulate sending gui events to a 
component and see how Script objects and Handler objects work.

-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day