pythoncard-users Mailing List for PythonCard (Page 177)

Thanks a bunch, Neil. And this version of StandaloneZODB includes a
PersistentList, so now the textIndexer sample app runs without a hitch.
Things are getting better pretty quickly. This is good.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Neil
> Hodgson
> Sent: Sunday, February 10, 2002 6:09 AM
> To: po...@or...; Pythoncard
> Subject: Re: [Pythoncard-users] FW: [ZODB-Dev] RELEASED - StandaloneZODB
> 1.0 final
>
>
> Patrick K. O'Brien:
>
>
> > Can we get Neil to create a new binary Windows install for us?
>
> A binary installer:
> http://pythoncard.sourceforge.net/StandaloneZODB-1.0.win32-py2.2.exe
>
> A source archive:
> http://pythoncard.sourceforge.net/StandaloneZODB-1.0.zip
>
>    Neil
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Patrick K. O'Brien:


> Can we get Neil to create a new binary Windows install for us?

A binary installer:
http://pythoncard.sourceforge.net/StandaloneZODB-1.0.win32-py2.2.exe

A source archive:
http://pythoncard.sourceforge.net/StandaloneZODB-1.0.zip

   Neil

At 8:14 -0800 8/02/02, in message Pythoncard-users digest, Vol 1 #152 
- 9 msgs, pyt...@li... wrote:
>The major change since you posted this is the presence of the
>resourceEditor sample. As to the sample application, I'm easy so suggest
>away. Does anyone have a particular itch that they want to scratch?

I'd like to suggest to start with the skeleton of a real PIM 
(Personal Information Manager).
It should have :
- a real contact management with separate Company and individual 
cards with links (belong to). With variable number of fields for 
stroing phones (some contact I have can be reached on 5 different 
phones numbers ;-)
- A nice diary dealing with time constraints. With possibility of 
linking an event to a contact...
- a small project management part with simple constraints like "Start 
after end of task xx"
- A syncronisation feature for keeping in sync the same app on my 
home and work machine.
- provision for people to add other synching with Palm et all.

If it is built to be easily extensible, I think that it could be the 
Killer App of PythonCard.

Taking some time, I could probably write a more complete dream description.

Can we get Neil to create a new binary Windows install for us?

---
Patrick K. O'Brien
Orbtech

-----Original Message-----
From: zod...@zo... [mailto:zod...@zo...]On Behalf
Of Barry A. Warsaw
Sent: Friday, February 08, 2002 6:45 PM
To: pyt...@py...
Cc: pyt...@py...; zod...@zo...; zop...@zo...;
zop...@zo...
Subject: [ZODB-Dev] RELEASED - StandaloneZODB 1.0 final



I'm please to announce the release of StandaloneZODB, the Python
object persistency system also known as the Z Object Database.  ZODB
is the object-oriented database underlying Zope; the StandaloneZODB
project's goal is to provide those same facilities to non-Zope related
Python applications.

Today we are releasing StandaloneZODB 1.0 final.  A brief description
of the changes since release candidate 1 is outlined below.

StandaloneZODB is based on the same code as the ZODB in Zope, albeit
on a separate release branch.  Its inspiration comes from Andrew
Kuchling's StandaloneZODB project on SourceForge.  While there are
still some differences, the Standalone 1.0 release is the first on the
path toward convergence.  Subsequent releases should complete the
merge of Andrew's and Zope Corporation's packages.

The StandaloneZODB release includes the following components:

    - Core ZODB, including the persistence machinery
    - Standard storages such as FileStorage
    - Supporting modules such as ExtensionClass
    - The persistent BTrees modules
    - ZEO
    - Experimental Berkeley storages
    - Some documentation <wink>

See the README file for details on building and installing
StandaloneZODB.  For details on using ZODB, see Andrew's included user
guide.

StandaloneZODB 1.0 is released under the ZPL 2.0.  It should be
compatible with all Python versions from Python 2.1 to Python 2.2.  It
may or may not work with versions earlier than Python 2.1.

Download StandaloneZODB-1.0 from:

    http://www.zope.org/Products/StandaloneZODB

and visit the StandaloneZODB Wiki page at:

    http://www.zope.org/Wikis/ZODB/StandaloneZODB

See also:

    http://www.zope.org/Wikis/ZODB/FrontPage

for more information about our long-range ZODB plans.

Enjoy,
-Barry

Barry A. Warsaw
Zope Corporation, Pythonlabs
ba...@zo...

-------------------- snip snip --------------------
What's new in StandaloneZODB 1.0 final?
Release date: 08-Feb-2002
=======================================

All copyright notices have been updated to reflect the fact that the
ZPL 2.0 covers this release.

Added a cleanroom PersistentList.py implementation, which multiply
inherits from UserDict and Persistent.

Some improvements in setup.py and test.py for sites that don't have
the Berkeley libraries installed.

A new program, zeoup.py was added which simply verifies that a ZEO
server is reachable.  Also, a new program zeopack.py was added which
connects to a ZEO server and packs it.

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZOD...@zo...
http://lists.zope.org/mailman/listinfo/zodb-dev

The bulldozer files are available in CVS only. Feel free to check them out.
I can also zip a set of files for you if that would help.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Friday, February 08, 2002 5:21 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] ZODB, Bulldozer, and Addresses
>
>
> Patrick wrote:
>
> >Message: 3
> >Reply-To: <po...@or...>
> >From: "Patrick K. O'Brien" <po...@or...>
> >To: "Andy Todd" <an...@ha...>
> >Cc: "Pythoncard" <pyt...@li...>
> >Subject: RE: [Pythoncard-users] Priority One - Object Persistence
> >Date: Fri, 8 Feb 2002 11:27:22 -0600
> >
> >I agree with you, Andy. Let's not pick one, let's each pick
> whatever we want
> >and see what happens. I'm willing to help with them all. I may go with
> >MetaKit because I have a short-term need. I've done lots of stuff in the
> >past with SQL (though not with Python) so I can help a bit
> there. And I've
> >played with ZODB (see my Bulldozer project at
> >http://sourceforge.net/projects/bdoz/) and have a real interest
> in making it
> >work.
>
> Hey, Patrick! You been holding out on me, dude! :-)
>
> I'm interested in seeing what you've done here. It may solve my
> Python-Zope issues but if it doesn't I'm sure I'll learn a lot from
> it.  I notice you haven't released any files. Do you have anything I
> could look at?
>
> >As for sample apps, let's do a few. We'll keep them simple to begin with.
> >I'll probably start with Kevin's address sample, because it is
> already there
> >and working. I'd also like to create apps that I'll actually
> want to use. So
> >a to-do list would be nice, as well as a more feature-rich
> contact manager.
>
> I've started doing a shelve adaptation of the Addresses stack. I'm
> learning shelve as I go and still stumbling around a bit but I'm
> happy either to finish it as best I can and then turn it over or have
> you or someone else do this and then learn from it by reading. My
> plan was to do a ZODB/Zope adaptation next for learning purposes.
> --
> Dan Shafer, Personal Creativity Trainer and Consultant
> Trained Hartman Value Profile Analyst
> http://www.danshafer.com/valueprofile.html
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Patrick wrote:

>Message: 3
>Reply-To: <po...@or...>
>From: "Patrick K. O'Brien" <po...@or...>
>To: "Andy Todd" <an...@ha...>
>Cc: "Pythoncard" <pyt...@li...>
>Subject: RE: [Pythoncard-users] Priority One - Object Persistence
>Date: Fri, 8 Feb 2002 11:27:22 -0600
>
>I agree with you, Andy. Let's not pick one, let's each pick whatever we want
>and see what happens. I'm willing to help with them all. I may go with
>MetaKit because I have a short-term need. I've done lots of stuff in the
>past with SQL (though not with Python) so I can help a bit there. And I've
>played with ZODB (see my Bulldozer project at
>http://sourceforge.net/projects/bdoz/) and have a real interest in making it
>work.

Hey, Patrick! You been holding out on me, dude! :-)

I'm interested in seeing what you've done here. It may solve my 
Python-Zope issues but if it doesn't I'm sure I'll learn a lot from 
it.  I notice you haven't released any files. Do you have anything I 
could look at?

>As for sample apps, let's do a few. We'll keep them simple to begin with.
>I'll probably start with Kevin's address sample, because it is already there
>and working. I'd also like to create apps that I'll actually want to use. So
>a to-do list would be nice, as well as a more feature-rich contact manager.

I've started doing a shelve adaptation of the Addresses stack. I'm 
learning shelve as I go and still stumbling around a bit but I'm 
happy either to finish it as best I can and then turn it over or have 
you or someone else do this and then learn from it by reading. My 
plan was to do a ZODB/Zope adaptation next for learning purposes.
-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

I improved PyCrust support for ZODB/Zope by extending the namespace viewer
so that it now allows you to drilldown into all the items stored in ZODB
BTrees, which act much like Python dictionaries. This enhancement is
available in the CVS version.

This has been tested with Python 2.2 and the latest StandaloneZODB. As I
intend to support ZODB as much as possible, please let me know any problems
you run into, or features you would like to see.

---
Patrick K. O'Brien
Orbtech

I'm forwarding this to the Pythoncard list in case anyone else wants a
precompiled version.

---
Patrick K. O'Brien
Orbtech

-----Original Message-----
From: zod...@zo... [mailto:zod...@zo...]On Behalf
Of Kevin Altis
Sent: Tuesday, January 29, 2002 11:00 PM
To: zod...@zo...
Subject: [ZODB-Dev] FW: standalone windows 1.0rc1 exe


If anyone wants to grab it, Neil Hodgson was nice enough to make a
non-optimized exe build for Python 2.2 at the URL below.

I haven't been able to run the PythonCard textIndexer sample because of the
following imports, it can't find PersistentList. That worked with the
StandaloneZODB that Neil compiled last summer using Andrew's distribution,
but I guess it has been renamed since then? The other imports work fine.

import ZODB
from Persistence import Persistent
from ZODB.PersistentList import PersistentList
from ZODB import DB, FileStorage
import BTrees
from BTrees import OOBTree

ka

-----Original Message-----
From: Neil Hodgson [mailto:ne...@sc...]
Sent: Tuesday, January 29, 2002 5:48 PM
To: Kevin Altis
Subject: Re: [ZODB-Dev] need Windows binary for StandaloneZODB 1.0 rc1


Kevin:
> Neil, I think you built standalonezodb last summer. Do you want to see if
it
> builds a win32 exe distribution correctly just using distutils on your
box?
>
> That's probably:
>   python setup.py bdist_wininst
> I don't know if formats=zip would do the compilation?
>   python setup.py sdist --formats=zip

   The first makes a binary installer, the second just a source archive:
http://pythoncard.sourceforge.net/StandaloneZODB-1.0b1.win32-py2.2.exe
http://pythoncard.sourceforge.net/StandaloneZODB-1.0b1.zip
   Funny that it is building b1 and the download was for c1.

   If you want a free copy of Microsoft's C++ compiler so you can attempt to
do this sort of thing yourself, then download the .NET SDK - 140 megs +
maybe 4 times that temporarily during install.
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?ur
l=/msdn-files/027/000/976/msdncompositedoc.xml

  Its only the non-optimizing version of the compiler but that's all I use
normally as gcc can be used for optimised builds of my code.

   Neil




_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZOD...@zo...
http://lists.zope.org/mailman/listinfo/zodb-dev

> From: Dan Shafer
>
> I'm not sure I really care of ZODB is the native PythonCard data
> model. What I need is the ability to interact with a ZODB. More
> specifically, I need to craft PythonCard apps that retrieve data from
> and write data back to Zope. I've long since standardized on Zope as
> my app and content management framework and I have zero interest in
> changing that at this point. I have created a number of sites for
> friends and clients in Zope and we now want to create app-style
> interfaces to get at the data stored there. For me, then, PythonCard
> in that set of apps becomes a UI toolkit with smarts that lets me do
> things the browser won't.
>
> Kevin says this is more like screen scraping than object storage. OK.
> Whatever I call it, it's what I want.

Here's one definition that popped out of a google search for "screen
scraping"
http://www.tuxedo.org/~esr/jargon/html/entry/screen-scraping.html

So just a clarification to my original comment. It is only screen scraping
if the only data you can extract from the database is HTML and you have to
then parse that to get any meaning out of the content.

The obvious problem with a screen scraping solution such as getting stock
quotes from a page like: http://finance.yahoo.com/q?s=intc&d=v1 instead of
from a web service that returns XML... is that if Yahoo changes the HTML
your parsing code for extracting the stock quote will probably break.

Hopefully your ZODB database contains real fields and is only turned into
HTML once it goes through some template processing.

ka

I smell a sample brewing, anyone care to take a shot at using this stuff? If
not, just consider this a placeholder in the mailing list archive until
someone wants to dig deeper into it. I haven't looked into charting (other
than a little SciPy) or this package myself, I just read Mark's blog post
and thought, wow, we could do that interactively.

GDCHART
http://www.fred.net/brv/chart/

The Python wrappers
http://athani.pair.com/msteed/software/gdchart/

Mark Pilgrim did a piece on it today.
http://diveintomark.org/archives/archive-022002.html#00000095

ka
---
From the home page...

Available chart types:
Line
Area (Mountain)
Bar
Floating Bar
HiLoClose*
Combo HLC Area*
Combo HLC Bar*
Combo Line Bar
Combo Line Area
Combo Line Line
Pie
Scatter
3D Line (Ribbon)
3D Area
3D Bar
3D Floating Bar
3D HiLoClose*
3D Combo HLC Area*
3D Combo HLC Bar*
3D Pie

Let me clarify my need. It may not conflict at all with what Patrick 
is saying about using MetaKit (which I found wanting because it is 
not a pure OODBMS which, in my experience, means we're going to slam 
into some serious brick walls as object complexity grows).

I'm not sure I really care of ZODB is the native PythonCard data 
model. What I need is the ability to interact with a ZODB. More 
specifically, I need to craft PythonCard apps that retrieve data from 
and write data back to Zope. I've long since standardized on Zope as 
my app and content management framework and I have zero interest in 
changing that at this point. I have created a number of sites for 
friends and clients in Zope and we now want to create app-style 
interfaces to get at the data stored there. For me, then, PythonCard 
in that set of apps becomes a UI toolkit with smarts that lets me do 
things the browser won't.

Kevin says this is more like screen scraping than object storage. OK. 
Whatever I call it, it's what I want.

So if my app needs to create _new_ objects that aren't part of the 
data my clients need for their apps, I don't care if we store it as 
lightwaves in a cube as long as it persists and as long as the 
persistence mechanism is transparent to me as a PythonCard user (by 
which I mean scripter).

I have not yet had time to investigate the matter fully but it seems 
to me likely that getting PythonCard to interact with Zope data ought 
to be a walk in the park since Zope is Python native. And since I 
don't need a standlone ZODB for my purposes, the issues associated 
with that are also irrelevant.

In the end, I think what I'm saying is that my app needs call for me 
to create perhaps some PythonCard components and pre-built apps that 
are Zope-aware and be done with it. Can't be that hard, right? Right. 
SMS (Simple Matter of Software).
-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

I agree with you, Andy. Let's not pick one, let's each pick whatever we want
and see what happens. I'm willing to help with them all. I may go with
MetaKit because I have a short-term need. I've done lots of stuff in the
past with SQL (though not with Python) so I can help a bit there. And I've
played with ZODB (see my Bulldozer project at
http://sourceforge.net/projects/bdoz/) and have a real interest in making it
work.

As for sample apps, let's do a few. We'll keep them simple to begin with.
I'll probably start with Kevin's address sample, because it is already there
and working. I'd also like to create apps that I'll actually want to use. So
a to-do list would be nice, as well as a more feature-rich contact manager.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> Andy Todd wrote
>
> Always ready for some fun.
>
> In the ZODB persistence thread I get the impression that Dan is firmly
> in favour of using it and that Kevin has some justifiable reservations.
> You are going to use MetaKit (damn, another set of documentation to
> peruse) and have looked at Webware but aren't pursuing it. I, meanwhile,
> have said previously that I will look into pickle/shelve and have built
> our only sample that talks to external storage (dbBrowser) which so far
> is a relational database.
>
> So, between us I think we have all the bases covered. The great thing
> about having such a range of skills and experience contributing to the
> project is that there is no reason we cannot try out all of them. I
> think that there is value in each of us trying out different tools and
> sharing our discoveries. This will cover all of the options and allow us
> to implement a component based persistence solution that allows the
> developer to switch in the back end they wish to use.
>
>
> Of course you have hit the nail on the head with your response to
> Rowland's post in the 'what do we call these things' thread. We need to
> decide on the data model that we are going to (try to) implement in all
> of these storage mechanisms otherwise we will end up with a number of
> incompatible solutions with different answers to the questions that this
> kind of application asks. I'm working on an Oracle backed PythonCard
> application that will raise some of these questions - particularly how
> do I tell the backend when the attributes of a displayed object have
> changed - and will share my bumbling about with you all.
>
> So what are you thinking about for a sample application, going back to
> your post from last year I see;
>
> """
> So if the goal is simple visual construction of screens that access
> transparently persistent data, I'd like to suggest that we embark on a
> joint effort to create such an application from scratch, using the tools
> that we have so far in PythonCard, as a way to flesh out further
> requirements. The development of this sample application could even be
> documented as a tutorial for others.
>
> If there is interest in this idea, here is what I think needs to happen:
>
> 1. Decide on a sample application that reflects the kind of app people
> would have done in HyperCard.
>
> 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.
>
> 3. Develop the app in a collaborative fashion to get feedback from more
> than one person.
>
> 4. Document as much as possible so that this serves as a tutorial
> of sorts.
>
> 5. Repeat for the next app until PythonCard is perfect.
> """
>
> The major change since you posted this is the presence of the
> resourceEditor sample. As to the sample application, I'm easy so suggest
> away. Does anyone have a particular itch that they want to scratch?
>
> Regards,
> Andy
> --
> -----------------------------------------------------------------------
>  From the desk of Andrew J Todd esq.
> "Its good to have an open mind, but not so open that your brains fall out"
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

I think one of the fundamental questions needs to be whether we want the
data storage to support multiple concurrent users. If not, then just about
any mechanism that can serialize Python objects to and from disk should be
good enough. That would include pickle, shelve, CSV, xml_objectify/pickle,
etc. But if you want multiple users accessing the same data at the same
time, you need to deal with update conflicts. That pretty much rules out the
previous options and gets us into ZODB, MetaKit, Gadfly, MySQL, PostgreSQL,
Oracle, etc.

Now, if we focus on the notion that Python objects are supreme, and we
simply want to persist them as they are (as opposed to accessing an existing
relational database or doing object/relational mapping), then we can
probably create a generic persistence mechanism that could be made to work
with all of these various backends. I mean, the operations may have diffent
names for each backend, but they all have similar functionality: open the
database, connect to it, get a set of objects, create a new object, update
the object, delete the object, save the object, display the first object,
display the next object, display the previous object, display the last
object, commit the transaction, rollback the transaction, resolve update
conflicts, etc.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> ke...@sp...
> Sent: Friday, February 08, 2002 10:40 AM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] What Do We Call These Things?
>
>
> Howdy,
>
> As a persistance mechanism is xml_objectify and xml_pickle being
> considered?
> comparison to XML-RPC
> http://www-106.ibm.com/developerworks/library/x-matters15.html#resources
>
> introduction;
> http://www-106.ibm.com/developerworks/xml/library/xml-matters1/index.html
>
> follow up;
> http://www-106.ibm.com/developerworks/xml/library/x-matters11.html
>
> Seems lightweight, transparent, and very easy to use.
> The objects live in XML, keeping options open.
>
> The latest IBM article mentions that the code is currently
> being enhanced.
>

Howdy,

As a persistance mechanism is xml_objectify and xml_pickle being=
 considered?
comparison to XML-RPC
http://www-106.ibm.com/developerworks/library/x-matters15.html#re=
sources

introduction;
http://www-106.ibm.com/developerworks/xml/library/xml-matters1/in=
dex.html

follow up;
http://www-106.ibm.com/developerworks/xml/library/x-matters11.htm=
l

Seems lightweight, transparent, and very easy to use.
The objects live in XML, keeping options open.

The latest IBM article mentions that the code is currently 
being enhanced.




On Fri, 08 Feb 2002 19:35:44 +1100, Andy Todd wrote:
>Patrick K. O'Brien wrote:
>
>>=A0My take on this is that a Hypercard application could be seen=
 as a
>>=A0collection of persistent object instances. In this case, each=
 object
>>=A0instance also knew about its display properties and could=
 override them. So
>>=A0the *class* would be "defined" to have a particular background=
 (with a set
>>=A0of buttons, etc.), but each *instance* (card) could have=
 specific additions
>>=A0(different background).
>>
>>=A0It seems to me that one could replicate much of this behavior=
 using the
>>=A0ZODB. But that would imply that we wanted the display=
 mechanism and the
>>=A0object data to be tightly intertwined and both stored in the=
 database. That
>>=A0is not how the Pythoncard framework is designed now. And I'm=
 not sure
>>=A0everyone would agree that this is a good idea. At the same=
 time, I don't
>>=A0think it would be too much of a stretch to imagine all the=
 Pythoncard
>>=A0resource files existing in the ZODB for the app. But then we=
 have the same
>>=A0problem as Zope - programmers want these kinds of things to be=
 text files,
>>=A0not buried in the database.
>>
>>=A0Just a bit of rambling.
>
>
>Rambling, possibly, but I think you have hit the nail on the=
 head. Our
>guiding principle should always by K.I.S.S. - no, not the make=
 up
>addicted band, but "Keep It Simple Stupid".
>
>We should make our central framework as elegant, simple and thin=
 as
>possible but make it easily extensible. Our default choices for=
 such
>things as persistent storage should be available to everyone,=
 but
>expandible to include more complex solutions for those who=
 require them
>(e.g. oodbms, rdbms, etc.).
>
>
>>
>>=A0---
>>=A0Patrick K. O'Brien
>>=A0Orbtech
>>
>>
>>>-----Original Message-----
>>>From: pyt...@li...
>>>[mailto:pyt...@li...]On Behalf=
 Of
>>>Francois Granger
>>>Sent: Sunday, January 06, 2002 3:22 PM
>>>To: pyt...@li...
>>>Subject: Re: [Pythoncard-users] What Do We Call These Things?
>>>
>>>
>[snip original message]
>
>>>
>
>Regards,
>Andy

http://www.zope.org/Members/bwarsaw/ipc10-slides

---
Patrick K. O'Brien
Orbtech

Patrick K. O'Brien wrote:

> Okay, folks. I'm ready to help tackle something that has been on my to-do
> list for a while now. And that is object persistence in Pythoncard. In my
> opinion, this is the one feature that could make Pythoncard different from
> every other development tool out there, and get us as close to Hypercard as
> we need to be to make all the former Hypercard developers happy. (Not that I
> can can speak for them, having never used Hypercard myself).
> 
> With this mesage I'm hoping to get the attention of anyone else who is
> interested in pursuing this. My idea is to use either MetaKit or ZODB and
> push it until it breaks. Sure, I like mySQL and PostgreSQL and Oracle and
> all the other SQL databases out there. But that isn't my goal. My goal is
> Python object persistence using native Python.
> 
> I think I'm going to look closely at MetaKit and ZODB and then pick one.
> I'll post my assessments to your list as I go. My immediate thought is that,
> while I'd like to go with ZODB, I may have to pick something like MetaKit in
> the short term. At least for my own app. I need something that is feature
> complete. ZODB is very nice, but hardly anyone is using it outside of Zope.
> I think it really needs to be part of Python, which is where they are
> heading. But that will take time. On the surface MetaKit sounds more
> complete. And the list of Python contributors is quite comforting - Cameron
> Laird, Gordon McMillan, Christian Tismer.
> 
> I do also like the Webware stuff, but their object persistence is yet
> another method, and has been developed primarily for mySQL. In some ways
> this is good, in that you do get some benefits from mySQL, but it adds to
> the complexity of what has to be installed. The other appeal to the Webware
> MiddleKit approach is that it could potentially support both a
> Webware/brower app and a Pythoncard/wxPython app from the same object
> database.
> 
> If the goal of Guido and company is to make a persistence database part of
> the core library, then I think it is in our interests to be one of the first
> tools to work with that. The question is, how much attention will this get
> and how serious are they about doing this. The lack of a Windows compiled
> install of standaloneZODB sucks royally and they don't seem to be in a hurry
> to create one.
> 
> So MetaKit could be a stepping stone on the way to ZODB. Or we might create
> a layer that works with either/both. I've played with ZODB so I know what
> some of the issues are. I'll have to look at MetaKit as well.
> 
> We talked about all this once before, and came up with some ideas for a
> sample application. But I didn't have time available to work on it. Now I
> do. Ready for some fun?
> 
> ---
> Patrick K. O'Brien
> Orbtech
> 
> 


Patrick, 


Always ready for some fun.

In the ZODB persistence thread I get the impression that Dan is firmly 
in favour of using it and that Kevin has some justifiable reservations. 
You are going to use MetaKit (damn, another set of documentation to 
peruse) and have looked at Webware but aren't pursuing it. I, meanwhile, 
have said previously that I will look into pickle/shelve and have built 
our only sample that talks to external storage (dbBrowser) which so far 
is a relational database.

So, between us I think we have all the bases covered. The great thing 
about having such a range of skills and experience contributing to the 
project is that there is no reason we cannot try out all of them. I 
think that there is value in each of us trying out different tools and 
sharing our discoveries. This will cover all of the options and allow us 
to implement a component based persistence solution that allows the 
developer to switch in the back end they wish to use.


Of course you have hit the nail on the head with your response to 
Rowland's post in the 'what do we call these things' thread. We need to 
decide on the data model that we are going to (try to) implement in all 
of these storage mechanisms otherwise we will end up with a number of 
incompatible solutions with different answers to the questions that this 
kind of application asks. I'm working on an Oracle backed PythonCard 
application that will raise some of these questions - particularly how 
do I tell the backend when the attributes of a displayed object have 
changed - and will share my bumbling about with you all.

So what are you thinking about for a sample application, going back to 
your post from last year I see;

"""
So if the goal is simple visual construction of screens that access
transparently persistent data, I'd like to suggest that we embark on a 
joint effort to create such an application from scratch, using the tools 
that we have so far in PythonCard, as a way to flesh out further 
requirements. The development of this sample application could even be 
documented as a tutorial for others.

If there is interest in this idea, here is what I think needs to happen:

1. Decide on a sample application that reflects the kind of app people 
would have done in HyperCard.

2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.

3. Develop the app in a collaborative fashion to get feedback from more 
than one person.

4. Document as much as possible so that this serves as a tutorial of sorts.

5. Repeat for the next app until PythonCard is perfect.
"""

The major change since you posted this is the presence of the 
resourceEditor sample. As to the sample application, I'm easy so suggest 
away. Does anyone have a particular itch that they want to scratch?

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Its good to have an open mind, but not so open that your brains fall out"

Patrick K. O'Brien wrote:

> My take on this is that a Hypercard application could be seen as a
> collection of persistent object instances. In this case, each object
> instance also knew about its display properties and could override them. So
> the *class* would be "defined" to have a particular background (with a set
> of buttons, etc.), but each *instance* (card) could have specific additions
> (different background).
> 
> It seems to me that one could replicate much of this behavior using the
> ZODB. But that would imply that we wanted the display mechanism and the
> object data to be tightly intertwined and both stored in the database. That
> is not how the Pythoncard framework is designed now. And I'm not sure
> everyone would agree that this is a good idea. At the same time, I don't
> think it would be too much of a stretch to imagine all the Pythoncard
> resource files existing in the ZODB for the app. But then we have the same
> problem as Zope - programmers want these kinds of things to be text files,
> not buried in the database.
> 
> Just a bit of rambling.


Rambling, possibly, but I think you have hit the nail on the head. Our 
guiding principle should always by K.I.S.S. - no, not the make up 
addicted band, but "Keep It Simple Stupid".

We should make our central framework as elegant, simple and thin as 
possible but make it easily extensible. Our default choices for such 
things as persistent storage should be available to everyone, but 
expandible to include more complex solutions for those who require them 
(e.g. oodbms, rdbms, etc.).


> 
> ---
> Patrick K. O'Brien
> Orbtech
> 
> 
>>-----Original Message-----
>>From: pyt...@li...
>>[mailto:pyt...@li...]On Behalf Of
>>Francois Granger
>>Sent: Sunday, January 06, 2002 3:22 PM
>>To: pyt...@li...
>>Subject: Re: [Pythoncard-users] What Do We Call These Things?
>>
>>
[snip original message]

>>

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

>From: Dan Shafer <da...@da...>
>
>Patrick suggested that we use ZODB for our PythonCard persistence.
>After looking into the shelve stuff and then looking at ZODB, my
>sense is that eventually we'd like to support both via an API that
>just deals with persistence.transparently.
>
>But in the near term, I'd personally prefer to use ZODB for a lot of
>reasons, some technical and some selfish. However, I wonder about
>what this does to the already limited universality of PythonCard.
>We'd require people to download a standalone ZODB as part of
>installing PythonCard (or bundle it with the install, bloating it in
>the process). We get shelve for free in Python.

Bloat is not yet an issue, but one already has to get Python and 
wxPython before using PythonCard.

Universality is a concern as well. And wauting for ZODBMac after 
waiting for wxPythonMac does not look good.

(Just my two Euro Cents ;-)

And it seems to me that we can build the solution without taking 
class changing into account, then retrofit it later. If we do a good 
job of OO design, we shouldn't paint ourselves into any inextricable 
corners. We can't anticipate all the issues we're liable to 
encounter, right?

I'm not sure how often class changes are made. When they are, some 
mechanism that monitors the out-of-synch situation and even alerts 
the user that s/he has to do something explicit to bring things back 
into alignment would be an OK first pass solution, wouldn't it?

>Not entirely true. With ZODB there is a standard method (can't remember the
>name) called on each object as it is retrieved from storage. So if the class
>has changed you build into that standard method the code required to deal
>with the change (add default values to new properties, etc.). Or you write a
>batch program that touches every single instance of the changed class and
>update existing values as necessary.
>
>Not necessarily ideal, but at least there are mechanisms.
>
>---
>Patrick K. O'Brien
>Orbtech
>
>  > -----Original Message-----
>  > Kevin Altis wrote:
>  >
>
>[snip]
>
>  > 7. One of my biggest concerns with ZODB as our general mechanism is also
>  > valid for Shelve, but Shelve would be easier to deal with.
>  > Namely, there are
>  > no good ways of dealing with data stuffed into an object database when you
>  > go and change the classes. Perhaps versioning and careful attention to
>  > backward compatible class changes will help, but this is a pretty
>  > fundamental issue.

-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

At 2:08 PM -0600 2/7/02, Patrick K. O'Brien wrote:
>Ooh, ooh, yes! I agree completely. At least at this point in the game. Let's
>pick one object persistence method and take it to the extreme. I think we
>should decide between MetaKit and ZODB. They seem to be the strongest
>options at this point. Anyone who wants to do SQL can still do so. But I'd
>really like to pursue one way of persisting Python objects from Pythoncard.

For my purposes, ZODB is the answer. Several of my apps are going to 
be adjunct to existing Zope sites.  MetaKit does not do anything for 
me. So my vote is we concentrate 100% on ZODB and go for it.

>---
>Patrick K. O'Brien
>Orbtech
>
>>  Dan Shafer wrote:
>>
>>  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
>>
>>  _______________________________________________
>>  Pythoncard-users mailing list
>>  Pyt...@li...
>  > https://lists.sourceforge.net/lists/listinfo/pythoncard-users


-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

At 3:02 PM -0600 2/7/02, Patrick K. O'Brien wrote:
>Well, we don't have complete freedom in this area. For example, in order for
>an object to be able to be persisted to a ZODB storage, that object's class
>(somewhere in the hierarchy) must inherit from the ZODB Persistent class. So
>in a way this is an all or nothing choice at some level. My inclination is
>to pick something, dive in with both feet, make it work, then step back and
>evaluate the situation to see if it is the right thing for Pythoncard in the
>long term. I need to get my hands dirty. (Plus I have a real app I need to
>build very soon.)

Absolutely. I'm in the same boat.

I'm off to look at MetaKit. I'll get back with reactions.

>---
>Patrick K. O'Brien
>Orbtech
>
>>  -----Original Message-----
>>  From: pyt...@li...
>>  [mailto:pyt...@li...]On Behalf Of Dan
>>  Shafer
>>  Sent: Thursday, February 07, 2002 1:35 PM
>>  To: pyt...@li...
>>  Subject: [Pythoncard-users] ZODB Persistence
>>
>>
>>  Patrick suggested that we use ZODB for our PythonCard persistence.
>>  After looking into the shelve stuff and then looking at ZODB, my
>>  sense is that eventually we'd like to support both via an API that
>>  just deals with persistence.transparently.
>>
>>  But in the near term, I'd personally prefer to use ZODB for a lot of
>>  reasons, some technical and some selfish. However, I wonder about
>>  what this does to the already limited universality of PythonCard.
>>  We'd require people to download a standalone ZODB as part of
>>  installing PythonCard (or bundle it with the install, bloating it in
>>  the process). We get shelve for free in Python.
>>
>>  So while I really agree with Patrick and would be inclined to prefer
>>  ZODB for all my projects, I just wanted to raise the issue about ZODB
>>  on the list for feedback.
>>
>>
>>  --
>>  Dan Shafer, Personal Creativity Trainer and Consultant
>>  Trained Hartman Value Profile Analyst
>>  http://www.danshafer.com/valueprofile.html
>>
>>  _______________________________________________
>>  Pythoncard-users mailing list
>>  Pyt...@li...
>  > https://lists.sourceforge.net/lists/listinfo/pythoncard-users


-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html

I can alter the TextField code to use the wxRightTextCtrl in place of =
the wxTextCtrl, and everything works great. But when I create a new =
RightTextField module, it isn't registered correctly. Its seems that the =
widget modules are added when named in the resource file, but it doesn't =
find the new module.=20

I also thought I would look at changing the existing TextField to add an =
alignment parameter. It seems to me that the widget should have left and =
right alignment as an option, instead of having 2 widgets. The code for =
this is also a bit complex, but I do think that if there is a simple =
method for adding widgets, then I could just roll my own. The result of =
my little exercise is to ask not for a specific widget =
(wxRightTextField), but for documentation or a tool to allow me to add =
my own widgets.=20

Thanks,

rl

Okay, folks. I'm ready to help tackle something that has been on my to-do
list for a while now. And that is object persistence in Pythoncard. In my
opinion, this is the one feature that could make Pythoncard different from
every other development tool out there, and get us as close to Hypercard as
we need to be to make all the former Hypercard developers happy. (Not that I
can can speak for them, having never used Hypercard myself).

With this mesage I'm hoping to get the attention of anyone else who is
interested in pursuing this. My idea is to use either MetaKit or ZODB and
push it until it breaks. Sure, I like mySQL and PostgreSQL and Oracle and
all the other SQL databases out there. But that isn't my goal. My goal is
Python object persistence using native Python.

I think I'm going to look closely at MetaKit and ZODB and then pick one.
I'll post my assessments to your list as I go. My immediate thought is that,
while I'd like to go with ZODB, I may have to pick something like MetaKit in
the short term. At least for my own app. I need something that is feature
complete. ZODB is very nice, but hardly anyone is using it outside of Zope.
I think it really needs to be part of Python, which is where they are
heading. But that will take time. On the surface MetaKit sounds more
complete. And the list of Python contributors is quite comforting - Cameron
Laird, Gordon McMillan, Christian Tismer.

I do also like the Webware stuff, but their object persistence is yet
another method, and has been developed primarily for mySQL. In some ways
this is good, in that you do get some benefits from mySQL, but it adds to
the complexity of what has to be installed. The other appeal to the Webware
MiddleKit approach is that it could potentially support both a
Webware/brower app and a Pythoncard/wxPython app from the same object
database.

If the goal of Guido and company is to make a persistence database part of
the core library, then I think it is in our interests to be one of the first
tools to work with that. The question is, how much attention will this get
and how serious are they about doing this. The lack of a Windows compiled
install of standaloneZODB sucks royally and they don't seem to be in a hurry
to create one.

So MetaKit could be a stepping stone on the way to ZODB. Or we might create
a layer that works with either/both. I've played with ZODB so I know what
some of the issues are. I'll have to look at MetaKit as well.

We talked about all this once before, and came up with some ideas for a
sample application. But I didn't have time available to work on it. Now I
do. Ready for some fun?

---
Patrick K. O'Brien
Orbtech

Not entirely true. With ZODB there is a standard method (can't remember the
name) called on each object as it is retrieved from storage. So if the class
has changed you build into that standard method the code required to deal
with the change (add default values to new properties, etc.). Or you write a
batch program that touches every single instance of the changed class and
update existing values as necessary.

Not necessarily ideal, but at least there are mechanisms.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> Kevin Altis wrote:
>

[snip]

> 7. One of my biggest concerns with ZODB as our general mechanism is also
> valid for Shelve, but Shelve would be easier to deal with.
> Namely, there are
> no good ways of dealing with data stuffed into an object database when you
> go and change the classes. Perhaps versioning and careful attention to
> backward compatible class changes will help, but this is a pretty
> fundamental issue.
>
> People interested in ZODB should join or at least follow the ZODB-dev list
> http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ZODB-dev
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Well, we don't have complete freedom in this area. For example, in order for
an object to be able to be persisted to a ZODB storage, that object's class
(somewhere in the hierarchy) must inherit from the ZODB Persistent class. So
in a way this is an all or nothing choice at some level. My inclination is
to pick something, dive in with both feet, make it work, then step back and
evaluate the situation to see if it is the right thing for Pythoncard in the
long term. I need to get my hands dirty. (Plus I have a real app I need to
build very soon.)

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Thursday, February 07, 2002 1:35 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] ZODB Persistence
>
>
> Patrick suggested that we use ZODB for our PythonCard persistence.
> After looking into the shelve stuff and then looking at ZODB, my
> sense is that eventually we'd like to support both via an API that
> just deals with persistence.transparently.
>
> But in the near term, I'd personally prefer to use ZODB for a lot of
> reasons, some technical and some selfish. However, I wonder about
> what this does to the already limited universality of PythonCard.
> We'd require people to download a standalone ZODB as part of
> installing PythonCard (or bundle it with the install, bloating it in
> the process). We get shelve for free in Python.
>
> So while I really agree with Patrick and would be inclined to prefer
> ZODB for all my projects, I just wanted to raise the issue about ZODB
> on the list for feedback.
>
>
> --
> Dan Shafer, Personal Creativity Trainer and Consultant
> Trained Hartman Value Profile Analyst
> http://www.danshafer.com/valueprofile.html
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users