[Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions

[normanwinn <nor...@on...>]

Kevin Altis asked:

>In particular, I would like to 
>hear about features that products like FileMaker Pro provide that are 
>needed for an OS tool that users could transition to without feeling 
>like they are taking a step backwards.
>
 
I'd like to start more positively. My major client would forgive a great 
deal if he got more speed. And I'm pretty sure he will get it if I go 
down this, the Python/PythonCard, road. I start with this comment as 
much of what Filemaker does is probably not worth reproducing providing 
the user experience in the new environment is perceived as positive.

Filemaker 7 has just come out and it is much slower than version 6. On 
moving to OS X we already took a speed hit so, in the four years I have 
been working on this thing, instead of hardware improvements making 
things slick it has all got slower. On top of this, FM7 requires 
relearning much of what one has done + obliges a rewrite. Hence the 
reason my search is on.

I looked at many possibilities, some commercial, some open source. The 
reasons my quest has brought me here are:

1) I liked python from the moment I started to play with it.
2) one of the wx demos (then on OS X - now working mainly on a PC) 
showed some really rapid responsiveness to events.


Here is what Filemaker gives:

No need to define field lengths for any type of field. This seems 
trivial but gives an amazing freedom in database design.

Pretty maintenance free. Most sites have no database expert. I have 
never lost data (have come pretty close). However, no rollback.

Almost transparently cross platform - some font and printing issues. But 
client (as opposed to FM Server) not available on Linux. This latter is 
political as, now that the Mac is Unix based, doing the port would 
involve little work.

No connection hassles. FM mixes data, scripts, layouts and stuff all in 
one file per database (in FM7 this become per table).

An integrated form designer that, being designed for the purpose of 
databases, is pretty easy to use.
Same tool is used to design reports.

A relationship model that makes one to one, one to many, many to many, 
many to one relationships pretty easy to get a grasp of. (At least 
that's how it seems now, looking back).

Where SQL would use scripts (I believe) to select a group of records, FM 
frequently uses calculation fields as part of the relationship.

Calculations can appear in scripts as well as field definitions. These 
make great use of an extensive set of 'Status' functions.

FM is responsive to what is showing on the screen. If you haven't seen 
this it needs some explanation. If you go to a layout that contains 
references to another file(file = table in version < 7) then that file 
gets opened. If you open that layout in a small window only what is 
showing and referenced gets opened.

Pretty neat pop-up lists that can be up to 64k characters (much more in 
v7). On clicking in a field that has a pop-up the list becomes live to 
the keyboard i.e. typing 'be' takes one to entries beginning with 'be'. 
These lists can be based on
a) custom values
b) a value list from another file
c) the values from a field
d) the values from a field via a relationship.
One pretty neat thing here is that a relationship can be defined from 
virtually anywhere - deep withing the creation of a value list or during 
field definition or script creation.

However, there is no inbuilt type-ahead searching.


What is horrible and nasty:

No event based scripting.

No automated field or layout creation. Nothing of this type can be done 
on the fly.

Can't get at the controls when some speed tweaks are needed.

Incremental back ups are difficult to implement. Built in back up method 
can be slow as much more than the raw data is getting backed up. Can 
export fields and specify just data fields. Problem is that this process 
cannot be dynamically scripted.

Wide area network performance is lamentable as, at start up, the whole 
caboodle has to be dragged over the wires before anything happens. (This 
is another one that would lead my client to accept re-learning an interface)

Every user has to have a full copy of FM - form designer, script maker 
et al included. This is expensive and adds unnecessary security risks 
(there is a so-called kiosk version but these are not net workable).

Limited ability to produce dynamic dialogues.

Poor documentation once above novice level. Poor response to bugs and 
queries from FM, the company. (Happily, there are a couple of good lists).

Can't save or access scripts as text so can't cut and past chunks.

Until v7, no application wide globals, no parameters for scripts (a 
nightmare).

Oh, I forgot - no variables. Filemaker uses what it call 'global fields' 
for this. A real pain.

No regular expression searches. No wildcards.

__________________-

Apologies if I have been too detailed or not enough.

With all those downers some of you must be wondering why there is 
hesitation. It is worth noting that most Filemaker developers are doing 
quite nicely. FM, once mainly a Mac thing, now has 80% of new sales on 
Windows. And sales are (or at least, were, up till v7) growing fast. 
Many of these new users are tempted in by the ease with which 
rudimentary databases can be produced. They then come searching for guys 
like me when things get more complicated (as they inevitably do),

Norman Winn