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.

Rowland answered:

>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.



<<details of proposal snipped>>

I'm inclined to buy into the idea of a broader solution integrating 
the persistent store at the core of the document model into the 
framework architecture more tightly than just using an existing 
storage mechanism sort of "as is." Smalltalk, in particular, has 
developed some very strong and nicely generic design for 
change-notification mechanisms (though its native object persistence 
has always been a major gap).

OTOH, I think we need a sort of default mode for persistence that is 
simplified from a generic architecture and that can be transparent to 
end users (inventive users, scripting users, power users, whatever we 
want to call them), including those who want to create applications 
that rely on auto-storage of objects and documents without worrying 
about how that happens or understanding it.

So I'd suggest we architect the persistence mechanism into the 
framework API in such a way that the designer who is cognizant of 
storage alternatives or who is designing in an environment where the 
store is pre-determined can either use an existing component that 
handles that effort or follow clear guidelilnes for writing a 
component for a specific data storage need.

I'm also strongly predisposed to suggest that we emphasize _object_ 
store rather than relational models, which are always kludges when it 
comes to serializing and storing objects of any depth or complexity 
at all. Not to say we shouldn't allow SQL data storage of information 
stored in PythonCard applications, but only that our design and our 
default ought to be OO to the core, like the beautiful language we 
are using to craft it.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com