Contact, Event, and Workshop Managers

[Chad Walstrom]

Greetings.  It's been a long time since I've been actively involved with
GNUe.  I've finally found an opportunity to write application software
once again.  Our goal, replace the current Macintosh RAD-tool based
Workshop and Visitors Management software at the Institute for
Mathematics and its Applications.  The project can be split up into
three milestones.  1) Add functionality we currently don't have, and 2)
Replace common tools both applications need, and 3) Replace old custom
routines.

The software can be broken down into a few modules: Contact Manager,
Event Manager, Abstracts/Document Manager, and Visitor Manager.  In the
interest of not duplicating work, I wanted to tap into an existing
project and add my resources rather than reinvent the wheel.  Python,
PostgreSQL, and some web accessibility are requirements for the
software, and a separation between the business end of the app from the
UI end is essential.  GNUe hits all the bases.

Although I would like to see a tighter integration between Python
classes and objects and their representation in the RDBMS, I'm willing
to settle with the binding database table data to forms directly.
Still, I've been unable to wrap my skull around anything but a simple
table form.  The particulars of the master/detail relationship in GNUe
Forms eludes me.  I've tried to use the designer, but results have been
non-existant.  For highly normalized databases, I'm stumped with how
GNUe Forms works.

So, before I start digging into the source code step-by-step (which I'll
likely do anyway), can you give me a bird's eye view of GNUe Forms, it's
syntax, and how one-to-multiple relationships can be presented on a form?
For example, here's a simple person->address relationship I've set up in
a PostgreSQL table.

    person      person_addr address     address_type
    ----------- ----------- ----------- ------------
    id          id          id          id
    name        person_id   line1       name
    middle      address_id  line2       descr
    surname     addr_type   line3
    prefix                  city
    suffix                  state
    informal                zip
    
The person_addr, which represents the relationship between the three
other tables, would be considered the "master" and the three other
tables would be considered "detail" tables.

I've looked for sample forms that mimic this behavior and haven't run
across anything yet.  In hindsight, I don't really want to redesign any
contact manager you might have planed/working, so if there's something
in existence, let me know.

Regardless, the question is the same.  In highly relational databases,
how do I represent these complex ideas in your forms?

-- 
Chad Walstrom <address@hidden>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr

pgpGCVsl7zOg7.pgp
Description: PGP signature