pythoncard-users Mailing List for PythonCard (Page 180)

wxPython-Mac mailing list
http://lists.wxwindows.org/mailman/listinfo/wxpython-mac

The archives are at:
http://lists.wxwindows.org/pipermail/wxpython-mac/

For those of you wanting to help or just follow the progress of the wxPython
port.

ka

> From: Young-Jin Lee
>
> Hi, I'm new to PythonCard and I was trying to learn what PythonCard is.
> What is the similarity between PythonCard and HyperCard?
> Apple's HyperCard provides an easy way to construct an application for
> ordinary people. How does PythonCard help people to make an application? I
> tried to run the demos codes and looked at the source code. I expected
> PythonCard to provide a visual toolkit for application construction as
> HyperCard, but I couldn't find anything equivalent to it.
> Is there anybody to show me how PythonCard is similar to HyperCard?
> Thanks in advance. I'm looking forward to hearing your advice.

Just for clarification. PythonCard is not HyperCard. The first goal is to
produce a framework. We have runtime tools (Message Watcher, Property
Editor, Shell) and a layout editor (resourceEditor sample), but we don't
have an environment yet.

You can use the resourceEditor sample to build layouts for your
applications. Follow the tutorial provided as part of the counter sample.

PythonCard is using HyperCard for inspiration, but the project is only about
seven months old, so it will be a while before we have a complete
environment.

If you browse the archives, you will see some messages in the last month
that discuss the future of PythonCard.

ka

Hi, I'm new to PythonCard and I was trying to learn what PythonCard is.
What is the similarity between PythonCard and HyperCard?
Apple's HyperCard provides an easy way to construct an application for
ordinary people. How does PythonCard help people to make an application? I
tried to run the demos codes and looked at the source code. I expected
PythonCard to provide a visual toolkit for application construction as
HyperCard, but I couldn't find anything equivalent to it.
Is there anybody to show me how PythonCard is similar to HyperCard?
Thanks in advance. I'm looking forward to hearing your advice.

YJ

The dialognew.py module which contains the GenericDialog class won't handle
the same localization solution I used for the Background without a change to
its __init__. This is best illustrated by looking at a fragment of the
FindDialog class from textEditor.pyw

class FindDialog(dialognew.GenericDialog):
    def __init__(self, aBg, searchText='', wholeWordsOnly=0,
caseSensitive=0) :
        # load the resource
        path = os.path.join(aBg.stack.app.applicationDirectory,
'find.rsrc.py')
        aDialogRsrc = res.ResourceFile(path).getResource()
        dialognew.GenericDialog.__init__(self, aBg, aDialogRsrc)
 ...

As you can see, GenericDialog expects to receive a Resource, not a filename.
I think that I'm going to change the code so that only a string is passed to
the GenericDialog __init__ and then GenericDialog will use roughly the same
algorithm for loading the resource file as the Background class does. The
__init__ above would become

        dialognew.GenericDialog.__init__(self, aBg, 'find')

I'll think about this some more before checking anything in tomorrow.

ka

> From: Neil Hodgson
>
> > I'm already inclined to have an
> > 'international' or 'localized' folder where the resource files
> other than
> > the default English, United States file are stored to reduce clutter.
>
>    A folder containing ancillary files is reasonable. I read some
> of the OS
> X development documents a few months ago and thought the way it used
> directories to hold applications was very good although I can't
> remember the
> details.
>    It'd be sensible to avoid assuming that US English will be the original
> language for all applications.

Actually, the code I added will just use the default resource file
regardless of the default locale setting for language and/or country.
Continuing with the minimal sample, if someone had created minimal.rsrc.py
in German and I ran that on my system (English, United States, en_US) I
would see the German unless I provided a minimal.en_US.rsrc.py or
minimal.en.rsrc.py file to match my locale.

Hmm, I wonder if we could get bit by case-sensitivity on some OS platforms?
Probably not as long as we don't support a country-specific resource file
naming that only specifies the country code, aka minimal.US.rsrc.py

The code does not deal with the case of the user supplying the resource file
name as part of the initialization. For example, here's an alternative
startup in SourceForgeTracker.py

    app = model.PythonCardApp(Tracker,
'SourceForgeTracker.original.rsrc.py')

I left the option of overriding the default to simplify having a separate
resource based on OS platform or if you wanted to easily test a variation of
a layout. If we do support platform-specific naming conventions for resource
files, then the resource file name rules will need some tweeking.

Lately, I have been thinking that we should drop the .py file extension
since the resource files are not executable, but then we wouldn't be able to
use import instead of eval(), or would we? Would a .rsrc extension conflict
with an existing extension on Linux, Windows, Mac? If we move to XML
eventually, then the extension should be .xml. Details to decide on another
day.

ka

Kevin:

> I'm already inclined to have an
> 'international' or 'localized' folder where the resource files other than
> the default English, United States file are stored to reduce clutter.

   A folder containing ancillary files is reasonable. I read some of the OS
X development documents a few months ago and thought the way it used
directories to hold applications was very good although I can't remember the
details.
   It'd be sensible to avoid assuming that US English will be the original
language for all applications.

   Neil

I modified version of my original post to the list, responses from readers
and a follow-up are online at:

http://altis.manilasites.com/2002/01/21

http://altis.manilasites.com/2002/01/22

Dan Shafer provided the following comments via email, so they are not part
of the online responses.

ka
ps. Due to the story being picked up by both Scripting News
http://www.scripting.com/ and Dr. Dobb's Python-URL!
http://www.ddj.com/topics/pythonurl/ we're getting a reasonable amount of
derivative traffic to the PythonCard site.
---

Dan says:

I think the most important and telling part of this message for _me_ is:

>
>The resourceEditor sample, which is one of the more complex PythonCard apps
>I've done so far, is still only 1500 lines long; and a total hack job to
>boot ;-). Obviously, that isn't a big beast like Word, Excel, or
>Photoshop... but one person can't write those types of apps and that is
>probably the sweet spot I'm aiming at (one person or a few people coding
>efforts) and for the type of complexity one person might come up with,
>Python ends up as the best choice.
>

One-person apps fall into two categories for me:

1. Apps (stacks) which consist 90% of component assembly and wiring
(which may involve high-level scripting) and only 10% of scripting
(where 99% of functionality can be pre-defined and packaged).

2. Components which consist largely of Python code written to the
framework API creating the things the first kind of sole developer
glues together.

This, to me, says that a sole app developer _could_ build a _huge_
and very complex app, _provided_ he had access to the components
needed. This has always, for me, been the unfulfilled promise of OOP
becuase no OOP language has ever developed in an atmosphere where its
inventors/developers were at all interested in inventive users. I
fervently hope and strongly desire that PythonCard become that
environment and tool. If it does, I may decide to homestead there for
a very long time indeed.

But first we gotta get wxPython working on a Mac!
--
Dan Shafer, Author-Consultant

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Sunday, January 20, 2002 1:35 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] FW: Python is just as good as C++ for real
> apps
>
>
> I recently exchanged the following emails with someone that posted on
> wx-users asking about porting from Visual Basic (VB) to
> wxWindows. Like many
> people, especially people using C++, he is under the mistaken impression
> that Python is not good for building real apps. For the most part, I think
> that is simply wrong. My arguments in favor of Python are below. The
> messages are in order of most recent at the top to oldest at the bottom. I
> removed the original posters name, email and signature.
>
> I'm sure if I misspoke below, Neil or other C++ coders that use
> Python will
> correct me. They might even have points to add that I overlooked. I didn't
> even get into all the downsides of programming in C++.
>
> ka
> ---
>
> From: Kevin Altis
> Subject: RE: VB -> wxWin
>
> It depends on what you mean by big apps. If you are worried about speed of
> the menus, windows, widgets, event handling, etc. that is a non-issue. If
> you are worried about having access to lower-level OS routines, that again
> is generally a non-issue. Either there is a Python library that already
> provides access or it is a relatively painless affair to wrap the needed
> C/C++ so that it can be used directly by Python. Python has much better
> built-in cross-platform support than C++, even with the wxWindows library.
> You can even call Python from within C/C++ or inline C/C++ code in Python.
> Python has threads. Python has profiling tools to isolate which section of
> your code might need to be optimized or rewritten in C/C++.
>
> There are drawing samples for wxPython and I have put some drawing samples
> into PythonCard as well. These are actually a bit slower than they need to
> be because I did a double-buffered bitmap widget that should have some of
> the operations moved into C, but it is surprisingly fast as is.
> The speed is
> mostly a matter of the video card used. My hopalong sample is
> comparable in
> speed to the version I did in Java.
>
> The only way to know for sure if your particular application would have
> execution speed issues is of course to try it. However, the
> assumption that
> Python is somehow inferior to C++ for real apps is just plain wrong. Your
> initial message prompted my reply because your original code was in VB and
> you definitely aren't going to lose anything going from VB to
> Python except
> the simplicity of using COM components; you can use COM from
> Python, it just
> isn't as simple as from within VB. You should seriously consider
> Python and
> wxPython as a solution.
>
> ka
> ---
>
> Subject: Re: VB -> wxWin
>
> Thank you, but I'd rather stay with C++. Although Python is a very
> interesting programming language, it is more for scripting than
> creating big
> app's.
>
> ---
> From: Kevin Altis
> Subject: RE: VB -> wxWin
>
> If you would like to program in Python (and everyone should :)
> you can check
> out PythonCard
>   http://pythoncard.sourceforge.net/
> This isn't just a random plug. Many of the good things in VB are
> influencing
> the design of the framework, some naming conventions for event handler
> readability, how the layout editor works, etc. If you need them, you can
> build standalone EXEs using py2exe or Gordon McMillan's
> installer. There are
> screenshots of some of the samples (there are over 20 samples) that come
> with each release:
>   http://pythoncard.sourceforge.net/samples.html
>
> PythonCard sits on top of wxPython so you can use the
> wxPython/wxWindows API
> code in a PythonCard app in addition to our wrappers which are designed to
> simplify the "raw" wxWindows API.
>
> It won't help you with automatic code translation from VB to Python or
> translating your VB forms into PythonCard resources (layouts). The
> resourceEditor sample, while primitive, will help you quickly
> recreate your
> layouts.
>
> I would very much like to get feedback from a VB user such as yourself on
> features you really need or would like to see added.
>
> The only problem I see based on your requirements is that there
> isn't a firm
> date on the wxPython Mac port other than Real Soon Now.
> PythonCard/wxPython
> runs fine on Linux/GTK. It is possible to run GTK under OS X.
>
> ka
> ---
>
> Subject: VB -> wxWin
>
> Does anybody have experiences translating a Visual Basic program into a
> wxWindows application? Maybe a tool which does that?
>
> I have got about 10 programs written in VB3 or VB6 which I have to make
> running under Mac and Linux, all of them
>     - not using any databases
>     - not using any complicated ocx or dll (just vb runtime)
>     - relatively clean, uncommented vb code
>     - few Windows API calls (like BitBlt)
>
> I thought about writing a program/script which translates the
> "Visual" into
> "wxWindows" and the "Basic" code into "C++". I think this should
> be possible
> up to some small code parts which I would translate manually.
> Is there already such a tool? Does anybody have experiences in doing such
> things, maybe converting from other languages?
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

At 9:36 -0800 22/01/02, in message Pythoncard-users digest, Vol 1 
#144 - 10 msgs, pyt...@li... wrote:
>From: "Kevin Altis" <al...@se...>
>To: "pythoncard-Users" <pyt...@li...>
>Date: Tue, 22 Jan 2002 09:33:18 -0800
>Subject: [Pythoncard-users] vote results - PythonCard will now be known as...
>
>*** PythonCard ***
>
>No big surprise I guess. The vote was unanimous.

Hey ! when one comes with a good name, why change it ;-)

Francois sent along this note with a localized French addresses resource
file and some nice screen shots of the addresses sample running in French.
I'm not going to check this file into cvs, but French users can save it to
their addresses sample directory and use it.

There is a logic problem in the addresses.py source that I need to
"internationalize" before the "Show Notes/Hide Notes" button will work
correctly.

    def on_showNotes_command(self, target, event):
        if target.label == 'Show Notes':
            self.components.Notes.visible = 1
            target.label = 'Hide Notes'
        else:
            self.components.Notes.visible = 0
            target.label = 'Show Notes'

I can't remember exactly why I did the toggle that way rather than just
looking at the visible flag of the Notes field, so until I sit down and go
over the code again I'm not going to change it. Obviously, the string
comparison above won't work correctly with non-English text. This is
probably one of those situations where string resources are needed.

I was planning to expand the addresses layout so that the Notes were always
visible, so in that case the problem goes away entirely; there will no
longer be a Show Notes button.

The addresses sample shows that any standard dialogs we provide such as the
Find dialog need to have localized versions as part of the standard
distribution. I'm assuming that the native dialogs which are shown by the
dialogs sample use the native OS dialog and thus are already localized? The
text in the dialogs supplied by the source would still be in English.

ka

-----Original Message-----
From: Frangois Granger
Sent: Tuesday, January 22, 2002 10:18 AM
To: Kevin Altis
Subject: It is great and easy....


I guess that you will know what to do with the enclosed...

(direct from my office PC with Windows 2000 fr)

Dan Shafer wrote:

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


Sounds good to me.


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


I'm hoping that the storage model will be plug-n-play with the document 
model - I'm using the Form term introduced in earlier emails to refer to 
the document model.  Optimally, creating a new app using forms 
auto-magically gives the user persistence.  Persistence can be turned 
off if the user desires.


> 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 think the component object model needs to require change notification 
so that all components that have a 'value' can be expected to support 
persistence.


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


I agree on the need for an OO persistence model.

Talk to ya,
Rowland

I made a small change to model.py to support automatically loading a
localized resource file, if available. The function is at the end of this
message if you're curious. It checks the default locale when it starts up to
get the language and country abbreviations.

Francois sent me this debug output (use the -l logging option) from his
machine:
DEBUG: : Tue Jan 22 15:39:26 2002: default: ('fr_FR', 'cp1252')
DEBUG: : Tue Jan 22 15:39:26 2002: fr FR minimal.fr_FR.rsrc.py
minimal.fr.rsrc.py minimal.fr_FR.rsrc.py

In addition to the model.py change, I checked in a minimal.fr.rsrc.py file.
I dropped the country code since it should work for French users outside
France as well. If the sample had some string, currency, or other
differences that required the country code, the name would have been
'minimal.fr_FR.rsrc.py'; FR is the country abbreviation for France.

I have to make some much deeper changes in order to support automatic string
substitution when the resource file is loaded, but this will get us started
to identify issues. I might add a localize option to the resourceEditor in
the next release.

I don't want to check into cvs two or three (certainly not ten or more)
different localized resource files for every sample. If we have one sample
designed to test international issues then we can have a lot of different
localized versions for that one sample. The resourceEditor will almost
certainly have a lot of localized files. I'm already inclined to have an
'international' or 'localized' folder where the resource files other than
the default English, United States file are stored to reduce clutter.

Later we'll need to think about how users would find localized versions of
apps or where we might provide a place to get them, possibly automatically
via a standard web page, XML-RPC service, etc. Until the current resource
file loading is changed (it uses eval() but should use import) you don't
want people downloading random resource files to run on their local system.
Same problem as downloading and running any program or script, but in the
case of resource files, users wouldn't expect that the resource could be
dangerous.

BTW, the localized resource files work with standalones built with py2exe
and Gordon's installer (that package needs another name). The resource files
are distributed with the standalone or a user adds one later and when the
standalone starts up it loads the resource dynamically, just like it does
when you use the script. Cool, no?! Of course, the actual program needs to
be international aware in its logic and string handling too, so I'll get
strings into the resource format soon.

I'm glad we are starting this process now so that we can find a workable
long-term solution.

ka
---

def internationalResourceName(base):
    aFileName = base + ".rsrc.py"
    default = locale.getdefaultlocale()
    log.debug('default: ' + str(default))
    if default[0] != None:
        language, country = default[0].split('_')
        languageCountryName = base + '.' + language + '_' + country +
".rsrc.py"
        languageOnlyName = base + '.' + language + ".rsrc.py"
        if os.path.exists(languageCountryName):
            aFileName = languageCountryName
        elif os.path.exists(languageOnlyName):
            aFileName = languageOnlyName
    log.debug(language + ' ' + country + ' ' + languageCountryName + ' ' + \
              languageOnlyName + ' ' + aFileName)
    return aFileName

>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

> No, it was not unanimous. I didn't vote for PythonCard. However, i'm not
> surprised.
>
> Dave LeBlanc

The vote was unanimous, you either didn't email me your vote or it was lost
in the system. Sorry.

ka

No, it was not unanimous. I didn't vote for PythonCard. However, i'm not
surprised.

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, January 22, 2002 9:33
> To: pythoncard-Users
> Subject: [Pythoncard-users] vote results - PythonCard will now be known
> as...
>
>
> *** PythonCard ***
>
> No big surprise I guess. The vote was unanimous.
>
> Andy Todd did suggest possibly using the name Monty for the actual
> framework, but I'm not sure that it is necessary to make a distinction.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Kevin Altis <al...@se...>:
>
> *** PythonCard ***
> 
> No big surprise I guess. The vote was unanimous.

Heh... Cool :)

> 
> ka

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

*** PythonCard ***

No big surprise I guess. The vote was unanimous.

Andy Todd did suggest possibly using the name Monty for the actual
framework, but I'm not sure that it is necessary to make a distinction.

ka

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

Kevin Altis wrote:

> shelve is one option we have for creating persistant data. ZODB is another.
> We can't use something like anydbm, because the actual files created by
> anydbm aren't portable across operating systems, only the source is
> portable. Dan Shafer has started looking at shelve as described below. Those
> of you interested in this area should share your findings on the list.
> 
> The shelve module is documented at:
> http://www.python.org/doc/current/lib/module-shelve.html
> 
> There is an older tracker item for shelve as well:
> http://sourceforge.net/tracker/index.php?func=detail&aid=442150&group_id=190
> 15&atid=369015
> 
> ka
> ---
> 
> Dan Shafer opened up a new tracker item on shelve:
> http://sourceforge.net/tracker/?func=detail&atid=369015&aid=506564&group_id=
> 19015
> 
> Summary:
> Looking at shelve
> I had a chat with Kevin over the last day or two about
> document models and decided to dive into the
> development effort in a semi-modest way by looking
> into persistent object stores for PythonCard.
> 
> The shelve stuff looks very straight-forward and
> clean, so I'm going to take a first pass through a
> couple of quick tests with it.
> 
> It is very transparent, fully cross-platform, and
> handles any arbitrary Python object.
> 
> I'm not yet sure how this factors into or influences
> the document model. I think I can make this pretty
> transparent as long as we assume single-user stacks.
> The shelve we create can be given the same name as the
> stack/app transparently to the user.
> 
> My first step will be to take the Addresses stack and
> switch it from a text file to a shelve for storage,
> just to get my arms around the beast and to show two
> different document models. Then I'll take one of my
> old HyperCard stacks that makes more extensive use of
> storage and give it a whirl.
> 
> A shelve can be _opened_ for read access by multiple
> users but only the first one to open it gets write
> privileges (like FileMaker at least used to be), and
> there seems to be no way to control this (i.e.,
> explicit role or privilege assignment). I think that's
> perfectly acceptable, though, don't you?
> 
> Since I don't anticipate at this point that we'd even
> expose this to a user, who would simply get automatic
> data storage and retrieval a la HyperCard, I don't
> think we need to wrapper anything.
> 
> Exploring it has been fun.
> 
> Dan
> 

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
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

Hi all, and thanks for a very useful product!

I came to Pythoncard via textRouter, as I'm looking to make a blogger-api
compatible weblog with Zope-CMF, and textRouter has the makings of a great
tool for the client side of the equation.

I'm just taking my first steps into "pure" Python programming (coming from
Zope), so take my opinions with a large pinch of salt! :-)

As you can probably guess, my vote would be for ZODB. I can't give you
in-depth teachnical reasons, apart from "It's been around a long time, it's
got a lot of users... and Guido is on the Zope team!"

But I would point out that questions are often asked on the Zope
mailinglists about what tools to use for making GUI front-ends (for
LAN/desktop applications). wxPython is usually recommended, sometimes Boa.
But having a tool that "natively" talks Zope's language would be a hell of
an advantage, and could bring a lot of new users (and perhaps developers) to
Pythoncard!

Perhaps, even if you don't use ZODB as the storage mechanism, there could be
some kind of "Zope Module" available for Pythoncard?

Hope that makes sense!

Cheers, Jon

Jon Edwards
Pricom Ltd
www.pricom.co.uk

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: 21 January 2002 19:05

> I like the idea of shelve since it is simple and built-in to Python and I
> like the idea of ZODB because it will probably be built-in to
> Python 2.3 and
> provides more capabilities. Of course, use of ZODB probably also lends
> itself to some integration between PythonCard and Zope in the
> future, but we
> may be able to simply do that via XML-RPC.

David LeBlanc wrote:

> Gordon McMillan has a python wrapper for metakit called MkSql that puts a
> familiar facade on.
> 
> Dave LeBlanc
> 
> 
>>-----Original Message-----
>>From: pyt...@li...
>>[mailto:pyt...@li...]On Behalf Of Kevin
>>Altis
>>Sent: Monday, January 21, 2002 11:05
>>To: pythoncard-Users
>>Subject: RE: [Pythoncard-users] evaluating shelve module
>>
>>
>>
>>>From: Magnus Lie Hetland
>>>Sent: Monday, January 21, 2002 10:50 AM
>>>To: Kevin Altis
>>>Cc: pythoncard-Users
>>>Subject: Re: [Pythoncard-users] evaluating shelve module
>>>
>>>
>>>Kevin Altis <al...@se...>:
>>>
>>>>shelve is one option we have for creating persistant data. ZODB
>>>>
>>>is another.
>>>
>>>>We can't use something like anydbm, because the actual files
>>>>
>>created by
>>
>>>>anydbm aren't portable across operating systems, only the source is
>>>>portable. Dan Shafer has started looking at shelve as described
>>>>
>>>below. Those
>>>
>>>>of you interested in this area should share your findings on the list.
>>>>
>>>shelve is good... But if you're considering ZODB (i.e. C extensions),
>>>have you taken a look at MetaKit? It's a very nice little DB engine...
>>>
>>No. Is this the home page?
>>
>>  http://www.equi4.com/metakit/
>>
>>One requirement we have is that the storage mechanism needs to be usable
>>like a file and doesn't require a server process to be running. I
>>think that
>>rules out something like MySQL as simple default persistant data
>>store. Feel
>>free to share any MetaKit info you have.
>>
>>I like the idea of shelve since it is simple and built-in to Python and I
>>like the idea of ZODB because it will probably be built-in to
>>Python 2.3 and
>>provides more capabilities. Of course, use of ZODB probably also lends
>>itself to some integration between PythonCard and Zope in the
>>future, but we
>>may be able to simply do that via XML-RPC.
>>
>>ka
>>

And just to add my 0.7888 cents worth (damn that Australian dollar 
exchange rate) I currently plan to expand dbBrowser to support Gadfly 
(as there is now a patched version available for Python 2) and my next 
project is to re-write PyForm from the 2nd Edition of Programming Python 
in PythonCard - that uses shelve as a storage mechanism and has some 
pretty neat code in the back end that I shall be 'borrowing' wholesale from.

If I get a chance I will also take a look at Metakit and Gordons wrapper.

Progress will be reported as (and when) it is made ...

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

Gordon McMillan has a python wrapper for metakit called MkSql that puts a
familiar facade on.

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, January 21, 2002 11:05
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] evaluating shelve module
>
>
> > From: Magnus Lie Hetland
> > Sent: Monday, January 21, 2002 10:50 AM
> > To: Kevin Altis
> > Cc: pythoncard-Users
> > Subject: Re: [Pythoncard-users] evaluating shelve module
> >
> >
> > Kevin Altis <al...@se...>:
> > >
> > > shelve is one option we have for creating persistant data. ZODB
> > is another.
> > > We can't use something like anydbm, because the actual files
> created by
> > > anydbm aren't portable across operating systems, only the source is
> > > portable. Dan Shafer has started looking at shelve as described
> > below. Those
> > > of you interested in this area should share your findings on the list.
> >
> > shelve is good... But if you're considering ZODB (i.e. C extensions),
> > have you taken a look at MetaKit? It's a very nice little DB engine...
>
> No. Is this the home page?
>
>   http://www.equi4.com/metakit/
>
> One requirement we have is that the storage mechanism needs to be usable
> like a file and doesn't require a server process to be running. I
> think that
> rules out something like MySQL as simple default persistant data
> store. Feel
> free to share any MetaKit info you have.
>
> I like the idea of shelve since it is simple and built-in to Python and I
> like the idea of ZODB because it will probably be built-in to
> Python 2.3 and
> provides more capabilities. Of course, use of ZODB probably also lends
> itself to some integration between PythonCard and Zope in the
> future, but we
> may be able to simply do that via XML-RPC.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

How about Gadfly. It's portable Python. In use by a number of projects.
Leaves the door open for using other sql based solutions where performance
etc. is desired. If there's a dbi adaptor for it, all the better.

Dave LeBlanc
---
PyBorg - it's whats for dinner! ;-)

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, January 21, 2002 10:45
> To: pythoncard-Users
> Subject: [Pythoncard-users] evaluating shelve module
>
>
> shelve is one option we have for creating persistant data. ZODB
> is another.
> We can't use something like anydbm, because the actual files created by
> anydbm aren't portable across operating systems, only the source is
> portable. Dan Shafer has started looking at shelve as described
> below. Those
> of you interested in this area should share your findings on the list.
>
> The shelve module is documented at:
> http://www.python.org/doc/current/lib/module-shelve.html
>
> There is an older tracker item for shelve as well:
> http://sourceforge.net/tracker/index.php?func=detail&aid=442150&gr
> oup_id=190
> 15&atid=369015
>
> ka
> ---
>
> Dan Shafer opened up a new tracker item on shelve:
> http://sourceforge.net/tracker/?func=detail&atid=369015&aid=506564
&group_id=
19015

Summary:
Looking at shelve
I had a chat with Kevin over the last day or two about
document models and decided to dive into the
development effort in a semi-modest way by looking
into persistent object stores for PythonCard.

The shelve stuff looks very straight-forward and
clean, so I'm going to take a first pass through a
couple of quick tests with it.

It is very transparent, fully cross-platform, and
handles any arbitrary Python object.

I'm not yet sure how this factors into or influences
the document model. I think I can make this pretty
transparent as long as we assume single-user stacks.
The shelve we create can be given the same name as the
stack/app transparently to the user.

My first step will be to take the Addresses stack and
switch it from a text file to a shelve for storage,
just to get my arms around the beast and to show two
different document models. Then I'll take one of my
old HyperCard stacks that makes more extensive use of
storage and give it a whirl.

A shelve can be _opened_ for read access by multiple
users but only the first one to open it gets write
privileges (like FileMaker at least used to be), and
there seems to be no way to control this (i.e.,
explicit role or privilege assignment). I think that's
perfectly acceptable, though, don't you?

Since I don't anticipate at this point that we'd even
expose this to a user, who would simply get automatic
data storage and retrieval a la HyperCard, I don't
think we need to wrapper anything.

Exploring it has been fun.

Dan


_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Kevin Altis <al...@se...>:
...
> No. Is this the home page?
> 
>   http://www.equi4.com/metakit/

Yup.
 
> One requirement we have is that the storage mechanism needs to be usable
> like a file and doesn't require a server process to be running. I think that
> rules out something like MySQL as simple default persistant data store. Feel
> free to share any MetaKit info you have.
 
MetaKit does not require a separate process, and the file format is
platform-independent.

There is some simple documentation available from the web page about
the Python mapping. Very easy to use.

> I like the idea of shelve since it is simple and built-in to Python and I
> like the idea of ZODB because it will probably be built-in to Python 2.3 and
> provides more capabilities. Of course, use of ZODB probably also lends
> itself to some integration between PythonCard and Zope in the future, but we
> may be able to simply do that via XML-RPC.

Indeed.

> ka

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

> From: Magnus Lie Hetland
> Sent: Monday, January 21, 2002 10:50 AM
> To: Kevin Altis
> Cc: pythoncard-Users
> Subject: Re: [Pythoncard-users] evaluating shelve module
>
>
> Kevin Altis <al...@se...>:
> >
> > shelve is one option we have for creating persistant data. ZODB
> is another.
> > We can't use something like anydbm, because the actual files created by
> > anydbm aren't portable across operating systems, only the source is
> > portable. Dan Shafer has started looking at shelve as described
> below. Those
> > of you interested in this area should share your findings on the list.
>
> shelve is good... But if you're considering ZODB (i.e. C extensions),
> have you taken a look at MetaKit? It's a very nice little DB engine...

No. Is this the home page?

  http://www.equi4.com/metakit/

One requirement we have is that the storage mechanism needs to be usable
like a file and doesn't require a server process to be running. I think that
rules out something like MySQL as simple default persistant data store. Feel
free to share any MetaKit info you have.

I like the idea of shelve since it is simple and built-in to Python and I
like the idea of ZODB because it will probably be built-in to Python 2.3 and
provides more capabilities. Of course, use of ZODB probably also lends
itself to some integration between PythonCard and Zope in the future, but we
may be able to simply do that via XML-RPC.

ka

Kevin Altis <al...@se...>:
>
> shelve is one option we have for creating persistant data. ZODB is another.
> We can't use something like anydbm, because the actual files created by
> anydbm aren't portable across operating systems, only the source is
> portable. Dan Shafer has started looking at shelve as described below. Those
> of you interested in this area should share your findings on the list.
 
shelve is good... But if you're considering ZODB (i.e. C extensions),
have you taken a look at MetaKit? It's a very nice little DB engine...

> 
> ka

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org