Re: GUI from database schema? - Mailing list pgsql-general

I feel our gnue-forms/gnue-designer tools are pretty close.

On Tue, 22 Apr 2003, Jason Hihn wrote:

> The GUI builder will create an edit box for address1 with max chars=32,
> state will be a drop-down box with state abbreviations, and zip with be like
> address 1, but constrained to 10 chars.

Our designer's wizards can build the form from the schema.  I don't recall
if we autolimit the fields or not but we have the option.  As for
dropdowns we have a wizard that contructs them without too much hassle.
It's trivial to create fairly complex forms in minutes.  Said forms can
maintain multiple pages, with multiple tables, pulling from various
backends (mix and match postgresql tables w/ db2 tables w/ mysql)

We support all kinds of input validation, input manipulation,
primary/foreign key (what we call master/detail) links between tables
(fully supported by our wizards), form side event triggers with a
customized namespace to making working with form data easy.  On a single
backend based form you can even query detail tables and have the query
work it's way up thru the master records as long as the backend supports
it.

We provide drivers for dare I say most major database systems.

db2  gadfly    ingres     ldap   odbc    postgresql  sqlrelay
dbf  informix  interbase  mysql  oracle  sapdb       sqlite   sybase

For those from an Oracle background our gnue-forms client was inspired by
Oracle's SQL*Forms.  Several of us now feel we have exceeded the SQL*Forms
product in several areas such as multi-table support, scriptablity, db
support.


>
> For screen positioning, a layout table can be used:
>
> table | element | abs_position | control| ctrl_attrib | validate_func
> --------------------------------------------------
> address | address1 | (45,34) | NULL | NULL | val_addr_address()
> address | state    | (34,65) | NULL | NULL | val_addr_state_()
> address | ex_bool  | (34,32) | CHECKBOX | NULL | NULL


We do not do this.  Our layout info is stored in an XML based entry
gnue-form definition file (.gfd file).  Right now we do absolute
positioning but we've taken steps to provide layout managers.  The gfd
file can be sorted at almost any valid URI.


> Note that we have a couple options for the bool. It could be a drop-down,
> (with Yes/No) checkbox. Null will use the default. ctrl_attrib is a modifier
> like simple-list, etc.

Booleans are a major pain if represented by a checkbox.  We support this
but widget set designers seem to have issues with the idea of a 3 state
checkbox (Yes/No/Null).

>
> The positioning works well when absolute positioning is available, but not
> good for html. In that advent, the system can just refer to the control in
> the software as (table,element) and  the used in the place where it is to
> go:

Our forms tool uses plug-in UI drivers.  Wx, GTK2, QT, curses, win32 API,
and html are all in various stages of completion.  I'm not sure of the
html status at this time but I've seen demos of it. We're even tossing
around the idea of creating a Bayonne UI driver which would allow you to
create entry forms for use over a telephone.

Our widget set has a different focus that a standard widget set.  We focus
on the functionality of the widget and let the UI driver represent that
however it so chooses.  No input validation is allowed in the UI driver's
native widget.  It all gets passed back to a virtual form which tells
the driver what it can and cannot do.  A small example....

<entry name="foo" style="dropdown"....>

If the curses driver does not understand how to do dropdown it can fall
back to a standard entry.  Since the virtual form handles validation it is
still impossible for the user to enter bad data as input is still
validated.  While this wouldn't be ideal it does highlight how we attempt
to always fail into a useable state.

Using the various drivers requires no alterations to the .gfd file.  You
simply state the UI you wish to use like this...

gnue-forms -u curses form.gfd

If you don't specify a ui type it attempts to work it's way thru the
available drivers until it reaches curses.  If that fails the program
aborts.

>
> And then some platform-indep (Java? or native, but for the bog three
> platforms) reader does all the GUI code.
>

All our reference tools are written in python and work on most major
platforms (*nix, mac os X, win32).  At least one javascript based forms
client is also in the works but I don't know it's state.

> This force good design and business logic to be put in the database. Plus it
> makes it real easy for me because I'm about to start a project where I need
> web, native and curses layouts. Even if I need to do manual tweaking, it'd
> save me a lot!

Again, I think we're close.  We need to do some work to get our curses
support in line with out 0.5.0 release (unannounced for some reason :( )
but it is almost there, our win32 driver is really close as well, HTML I'm
not sure of the status on.

We're also very keen on keeping as much functionality in a common
framework as possible.  This means that enhancements in gnue-common ripple
out through our reports, forms, appserver projects as well.

Lots of other features I could talk about but this mail is long enough.

www.gnuenterprise.org

or join us in IRC at irc.freenode.net port 6667 channel #gnuenterprise

I think our biggest shortcoming is (of course) our documentation.  We are
aware of this and the 0.5.x series of releases are addressing that issue.

Take Care,
James

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson    138 Cardwell Hall  Manhattan, Ks   66506    785-532-0561
Kansas State University                          Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<