I rolled all the changes I was making to the flatfileDatabase.py module in
the companies sample back into the flatfileDatabase sample. Basically, the
version of the file in companies is a duplicate until the classes in
flatfileDatabase.py are merged into the framework. Since having two copies
is going to be a headache to maintain, I will probably go ahead and move
parts of flatfileDatabase.py into the framework later this week even if the
names of the module(s) will just be temporary.

There have been quite a few changes and numerous bug fixes. All of these
changes might mean that I've introduced some bugs, so be wary and back up
your existing data files if you are using flatfileDatabase for your own
work.

I added pickle support, so if your dataFile (defined in the config .ini)
ends in .pickle, a binary pickle will be used instead of the list/dictionary
text format. I do not recommend using the pickle yet except for testing,
since it is easier to view the text format and look for any problems in the
data. While flatfileDatabase is running, all data is maintained in memory as
a list of dictionaries, so the format of the storage is only different on
disk. If you have a big data set, you'll probably at least want to test the
data as a pickle because it is a lot faster to load and save. See the
saveFile method in the PickleDocument class for how you should convert your
data to a pickle.

As mentioned in a previous note, there is a find dialog and it lets you find
in all fields or a specific field. You can only search the 'string' fields
['CodeEditor', 'PasswordField', 'RightTextField', 'TextField', 'TextArea']

You can sort by string fields. Sorting does not currently cause the records
to be saved in the new sort order, but it would be easy to make that change
if desired.

I added a SetNow() method to the Calendar component.

The saveRecord method was completely refactored. The info below is sort of
advanced usage and just things I'm playing around with, so you can skip it
if you aren't concerned with the internals.

There is now a variable documentChanged to indicate when the records have
been updated. By default, the file is saved to disk whenever a change has
been made to a record and the app is changing the currently displayed
record, exiting, etc. That means there is no penalty of a disk write if you
are simply browsing data, but if you make a change, it is written as soon as
you move on, so there is little chance of data loss. There is a variable,
saveDocumentOnRecordChange, that can be set to 0 if for some reason you did
a subclass of the Document class and didn't want to automatically save.

I made a design change to saveRecord that may or may not be a good idea. The
basis for the storage in flatfileDatabase are the components and their names
defined in a resource layout. Let's say you create a layout with three
TextField components with the names: City, State, Zip. There is a one to one
relationship between the component name and the key in the dictionary. The
verbose way to represent an empty record as a dictionary is:

{'City': '', 'State': '', 'Zip': ''}

When you want to display the record, you get the component names and iterate
over them, putting the contents of each key in the corresponding component
in the view; that's what the Document displayRecord method does. You can
also iterate over the record keys and that's what the addresses sample does
which was the basis for the first version of flatfileDatabase.

It is also possible to only store fields that have non-default values, so in
the case above the record could just be:

{}

If the field is empty or contains a default value, you simply don't store
anything. While this saves some space it can be difficult to manipulate the
data, so I tossed that out in an earlier version of flatfileDatabase.

The change I made to the storage is that it is now legal to have record
fields without corresponding components in the view. So saveRecord will
update the fields with corresponding components in the current view, but it
won't delete any fields. This means that it is now possible to have
different views on the same data set without having to change the underlying
storage. The flatfileDatabase sample doesn't have the methods defined to
swap the view (resource) on the fly, but it would be easy for a subclass to
make the change. A more advanced app could manipulate the records directly,
say to store data that is never displayed.

Two fields I expect that I will add that won't normally be displayed are the
creation and modificaton times. The names will be something like '_created',
'_modified'.

Look at our component names above again: City, State, Zip. If you renamed
the 'Zip' component to 'ZipCode' the old 'Zip' field in each record won't be
lost. A script could then iterate through the records and copy the Zip field
value to the 'ZipCode' field. That should make it easier to move between
design/run modes among other things.

ka



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and much much more.
http://thinkgeek.com/sf
_______________________________________________
Pythoncard-users mailing list
Pythoncard-users@[...].net
https://lists.sourceforge.net/lists/listinfo/pythoncard-users