Re: [Pythoncard-users] Thinking about Filemaker replacement

[John M. <jm...@um...>]

I'm glad you brought up this thread again because I had been wanting to 
mention DABO:

http://dabodev.com/

This aims to be an open source Filemaker/FoxPro visual IDE replacement. 
 From their site:

"""
Dabo is a 3-tier, cross-platform application development framework, 
written in Python atop the wxPython GUI toolkit.

Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in 
database application development using the awesome and underrated 
Microsoft Visual FoxPro development environment.

While Visual FoxPro shines at developing data-centric applications, it 
has one limitation that cannot be ignored: it only runs on Microsoft 
Windows, and Ed and Paul both have clients that want their applications 
to run on Linux and Macintosh. We are sure we are not alone in this 
regard: it is a multi-platform world with more diverse needs than one 
vendor can fulfill.
"""

I'm wondering if there could be any useful cross-pollination between 
DABO and PythonCard?

John Miller

On Oct 14, 2004, nor...@on... wrote:

> I make an apology first. After an initial burst of activity, I  haven't
> been doing much in actually using PythonCard. This doesn't mean my
> interest has not been fired. However, my initial interest was my quest
> to see if a Filemaker replacement might be possible.
>
> What I have been doing is looking around in the open source community
> for the various components that might contribute to such an enterprise.
>
> Database engine:
> I have messed around with Firebird and it seems OK. Then I noticed that
> sqlite - that I had been avoiding - is not too fussy about storage 
> types
> and requires no pre-definition of data size. This would appear to offer
> a potential fit to the way Filemaker operates on data. The problem with
> sqlite - at least I think it is a problem - is that it is does not
> follow the client/server model. However, for the smallish companies 
> that
> dominate the Filemaker client base, sqlite may service requests rapidly
> enough for this not to be a problem.
>
> What may be being worked on is a front end queuing mechanism that will
> serve requests to sqlite. It appears that sqlite might evolve towards a
> client/server model.
>
> Sqlite is moving to version 3. This gives a choice of specifying data
> types or not which makes it an even better match for how Filemaker
> represents data.
>
> A reporting tool:
> Kevin Altiss found the excellent discussion on Filemaker replacement on
> slashdot. One comment in this thread made me realise how important an
> area Filemaker's reporting is. That thread also led me to DataVision
> (http://datavision.sourceforge.net/) which I haven't tried but looks a
> very promising report tool that would be much more powerful and 
> flexible
> than that of Filemaker.
>
> Extracting/converting data from Filemaker:
> pyFilemaker seems to extract as much as FM is willing to give. An
> interesting project in PythonCard would be to attempt to generate a
> default database front end from this information. This would only be
> bare bones compared with how the Filemaker front end would look, but
> often, having a place to start is enough to get one going.
>
> Well, this is not an exhaustive list of what would need to be done but 
> I
> thought it worth giving this report as the initial discussion seemed to
> generate interest.
>
>
> I must add in conclusion that I am enjoying learning Python and have
> produced a tool I use every day in relation to Filemaker. It is called
> 'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when invoked
> from the command line with the '-h' option:
>
> xpdBatch.py - extracts text from pdf files in current folder.
>              Depends on pdftotext from Glyph & Cog, LLC:
>                  http://www.foolabs.com/xpdf/
>
>     Usage: with no arguments processes pdf files not already done
>            If argument is:
>            a pdf file: (must be quoted if containing spaces) process
> that file
>            'all': (without the quotes) process all pdf files. Any 
> '.txt'
> files
>            existing will be overwritten.
>            -h: show this help
>
> I use it as Filemaker prints scripts only as pdf.
> Haven't tested it on the Mac yet but will.
>
> I have been very impressed by the patience and helpfulness of this
> community,
>
> Norman