Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 On Fri, 21 Jan 2005 18:55:27 +0000, Chris Green <chris@xxxxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
      message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux