I've checked in a very experimental sample, aka it will probably change a
lot between now and whenever the next release is. This is going to be a long
message as I try and get across what this sample does and doesn't do. I'll
probably post some follow-ups as it progresses too.

Yesterday I realized that most of the persistent storage issues that I
wanted to explore with the addresses sample had been left in limbo for quite
a while. Patrick is working on ZODB as a possible storage solution with the
addressesZODB sample. Except for a bug fix I haven't touched the addresses
sample in a long time. Anyway, while looking at addresses yesterday, I
realized most of the infrastructure was already in place for a generic
flatfile database application. The problem with addresses was that it wasn't
forcing generic solutions for the storage, sorting, and finding of data.

Fifteen minutes of pruning later a new sample was born. I spent additional
time adding features and now I've got something that other people can at
least play with.

The main idea is that the layout drives the underlying "fields" of each
record for the storage of data. The code doesn't define the data fields or
classes, they are created automatically based on the component names and the
component class/type determines the content type of the data field. This is
analogous to what you would get if you authored a single background layout
in HyperCard. You just create some components in a layout and bing you have
a flatfile database.

There is a template resource, flatfileDatabaseTemplate.rsrc.py, that you can
copy and then edit with the resourceEditor sample to define your own layout
and thus which data fields each record will have. The template already has
the basic File, Edit, and Go menus defined. If you want additional menus,
you'll need to add them and then modify the source code to support those
additional menus.

After looking at Juergen's custdb sample, I added ConfigParser support, so
which resource file and data file the app uses is determined by a setting in
the .ini file. Change those settings to suit your needs.

So, there are at least two ways you could use the flatfileDatabase sample.
The first would be if you didn't expect to change the source code. In that
case you simply open the 'flatfileDatabaseTemplate.rsrc.py' in the
resourceEditor, add the components to the layout with the names you want for
your data fields, then save the file with a new name, something like
'myDB.rsrc.py'. Then edit the 'flatfileDatabase.ini' settings file. Assuming
you wanted your data file named, 'myData.txt' the 'flatfileDatabase.ini'
file would read:

[ConfigData]
resourceFile = myDB.rsrc.py
dataFile = myData.txt

You can comment lines in the ini file you want ignored, so it is easy to
switch between the layouts and data files used simply by commenting out
different lines in the file. The second way to use flatfileDatabase would be
if you wanted to make changes to the source code. In that case, just copy
the whole flatfileDatabase directory, then rename files to your liking,
update the 'flatfileDatabase.ini' file and edit the resource file layout as
described above.

So far the field types I'm supporting are:

{'date':['Calendar'],
 'boolean':['CheckBox'],
 'integer':['Slider', 'Spinner'],
 'list':['Choice', 'List', 'RadioGroup'],
 'string':['PasswordField',
 'RightTextField',
 'TextField',
 'TextArea']
}

The 'list' components have a fixed set of items defined in the layout, so
only the selection on each record changes.

flatfileDatabase doesn't attempt to define a layout based on some existing
fields say in a csv or XML file, though that would be an interesting add-on
script and wouldn't be too difficult. If someone wants to do this the main
thing is to get a name for each data field and optional type and then build
a layout sort of like Andy Todd's dbBrowser sample does. The user could then
cleanup the automatically built layout.

I want to explore sorting and a more sophisticated find for the sample. I'm
thinking about supporting a special name prefix for fields in the layout
that should be ignored. It should also be possible to support a generic list
of all of the records like Juergen's custdb sample. Like sort and find
though, this needs to be done in a generic way, so that it is easy to
specify what gets displayed in the list without making assumptions about the
underlying data.

I expect that I will refactor the open file and save file methods of the
Document class so that a variety of formats can be used for storage,
including comma separated values (csv), XML, nested Python lists and
dictionaries, etc. If I can refactor the record loading and saving then a
larger variety of storage formats can be used, including single table MySQL
or remote storage via the web like xmlStorage.

It would be possible to have a single app that can open and maintain many
separate flatfile databases at once, but since this sample is aimed at
developers rather than end users that won't be doing any Python coding, that
solution seems less flexible.

One thing we might do in the framework later is support a basic module
and/or set of classes like those in flatfileDatabase and then you can simply
create subclasses of Document and FlatfileDatabase for your own apps. You
can do that now, but you'll need to do it directly from the
flatfileDatabase.py module.

Whew, that's a lot of info. Please post questions and I'll try and clarify
or expand on this post.

ka
---
readme.txt

flatfileDatabase implements persistent storage, transparent loading and
saving of the data to a separate text file. The limitation on data size is
that all data is read into memory when the application starts up and is
written to disk when the application exits.

This is not a robust storage solution, so by default a backup of the data
file is made prior to writing the new file. [KEA not implemented yet
2002-04-22]. Obviously, there will be startup and shutdown delays with the
app if you have a large set of data; large is relative ;-) If the app
crashes for some reason before making a clean exit (this is extremely
unlikely) then whatever changes were made since the last save will be lost.
I went ahead and added a File-> Save menu item so that the user could force a
data save while they're using the app.

The flatfile, textIndexer, and addresses sample provide the start of a
generic transparent data storage model for PythonCard that will eventually
be available to all PythonCard apps that want to use it. Patrick O'Brien's
addressesZODB sample explores the same issues using ZODB as the storage
format.


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