Re: Contact, Event, and Workshop Managers

[Derek Neighbors]

THis almost exact example is in our samples, I think some code changes 
have broken it slightly, I have a fixed version I will check in very soon, 
but you can get the general gist of it from the sample.

gnue/samples/tracker/

from your cvs/tar ball tree.....


It will have all the table scripts (postgres) and forms to manage all the 
different 'type' tables.  Then a contact_manager.gfd that puts it all 
together.  I have started to take this sample and replace its structs with 
real structs from DCL and to make a contact_manager that is fully 
compataiable with DCL for use by the Free Software Foundation. 

I would be more than willing to try iron out a common spec as much as 
possible and have a unified contact manager to help burden work load if 
you are interested.

-Derek



 On Tue, 11 Jun 2002, Chad Walstrom wrote:

> 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?
> 
>