Re: Data entry - forms design or other APIs etc. - what is there? - Mailing list pgsql-general

 On Fri, 21 Jan 2005 18:55:27 +0000, Chris Green <chris@areti.co.uk> wrote:
> > What methods are available to produce data entry forms for postgresql
> > databases?  If, for example, one wanted to migrate a system that used
> > Oracle Forms to Postgresql what would one use?  This seems to me to be
> > an area which is not aired much here and that surprises me because a
> > database is of no use unless one can get data into it.

gnue-forms (www.gnuenterprise.org) was created by a few of us that liked
Oracle forms but wanted something better (and free :).  It supports any
backend supported by our common library.  A listing of our backend drivers
dir displays ( in no order)

adodbapi   csv  dbf     informix  interbase  mysql  oracle      sapdb
sqlite    sybase  appserver  db2  gadfly  ingres    ldap       odbc
postgresql  special  sqlrelay

Some drivers are more feature complete than others but most should function.
Connections to backends are transparent to forms and other gnue-common based
apps.  So you can create forms on a postgresql backend (we have support for
all 4 python postgresql drivers), change one connections.conf file, and have
the forms work against the other databases listed above.

We also support several front ends including wx, gtk2, win32 native, and
curses(rough but functional in simple cases).

We have a separate gnue-designer tool that lets you drag and drop tables and
fields to create the XML based form files gnue-forms uses.  It also supports
wizards to create [single|multi]page master/detail forms.  Unlike the last
version of Oracle Forms (6?) I used our master/detail can nest to any level
without trigger kludges.  You can also mix and match datasources on the same
form so you could (for whatever reason) create master detail relationships
between tables on separate types of backends (I haven't tested that in years
though)    Also unlike Oracle forms our ui system lets you connect multiple
widgets on separate form pages to the same fields in a table, again to reduce
the number of triggers needed.

We do have a trigger system that lets you write triggers in python and
possibly javascript (i've never used the js support)  Custom namespaces let
you manipulate data via blockname.fieldname

Most of our tools functionality is embedded in our gnue-common library so you
can use the same datasources and types of access in custom programs as you
can in forms. If you're willing to use python that is :)  Common provides
more than just data access abstraction though, and it's description page
doesn't cover all it can do.  It contains an application framework, output
libraries for things like generating barcodes or tabular pdf reports,
formatting functions, a trigger system, and lots of other things.

We also have a report tool, and an n-tier application server (with it's own
forms backend driver).  All based upon the same common core.

We're happy to answer questions on our mailing list.  Or in IRC at
#gnuenterprise on irc.freenode.net

Take Care,
James