Re: [Pythoncard-users] evaluating shelve module

Andy Todd wrote:


> Whilst I'm thinking about storage and PythonCard, how does this 
> suggestion sound?
> 
> 
> We should leverage the component model that Rowland and Kevin are 
> currently building into the framework and expand it to cover storage 
> mechanisms as well.

> 
> This would not be an easy process as we would need to (probably) provide 
> our own storage API which would be used by the framework and/or the 
> PythonCard application. We would then need individual components which 
> would translate these PythonCard storage calls into working commands for 
> the underlying persistance mechanism. This way a developer can slot in a 
> component for the storage mechanism they want to use as they develop 
> their application and the framework/IDE don't need to worry about the 
> foibles of that particular storage module.
> 
> The reason I'm suggesting this is that I don't think we should restrict 
> ourselves to one specific storage mechanism. Each of the tools mentioned 
>  here is useful and useable but they have different strengths and 
> weaknesses.
> 
> I appreciate that by doing this we would add a different restriction, 
> that of 'normalising' the available functionality, but I think its a 
> worthwhile thing to think about at least.
> 
> Of course, with Python being OO we could implement the PythonCard 
> storage API and then implement extra, module specific, functions on top 
> of this.
> 
> Feel free to shoot me down in flames.
> 
> Regards,
> Andy

Sounds like a good plan to me.  I think it will be easier to narrow the 
focus of a storage solution to forms and form elements rather than a 
general storage api.

A form-centric solution would need to take into account creating
deleting, reading and updating forms in a persistent store, as well
as navigation ( first, previous, next, last ).

One take on this would be to define an event based change notification 
framework that could be used at a low level by Components.

On top of that, we could build a Form-centric storage model with 
concrete implementations for the various db's we want to support.

Change Notification

A component will notify a listener when it's internal 'data' has changed.

A component will listen for events indicating that it should update it's 
  internal 'data'.

Form Storage

Forms can be created, read, updated and deleted in a store.
An iterator provides navigation for a store ( first, previous, next, last ).

A store contains entry objects. An entry contains
objects that bind a component to an entry using the change notification
framework.

Scenario

Loading a form from a store:

A PythonCard app is opened, and it opens a window that displays a
form.  The form is registered with the form storage sybsystem.  At this
point the components that make up the form register with their listeners
and vice-versa.

The first form in the store is loaded.  The storage subsystem generates an
event updating the form and the form generates an event for each component
that is represented in the form entry.  Each component
in the actual form recieves an event containing the data that it should 
display.

Updating a form when a component's value changes:

When a component changes, it issues an event notifying any listeners
that it has changed, and what the new value is.

The form entry that is listening to the component receives the event,
updates itself, and then generates a form change event.

The form storage subsystem receives the form change event and updates
the form in a store.

Later,
Rowland