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
|
