Re: [gnome-db] Future characteristic

[Dru <andru treshna com>]

Adam Tauno WIlliams wrote:

> > > I think you're right.  This really limits the incentive to use Gnome-Db/GDA, if
> > > one still has to do all the form get/post grunt work.  And it needs to be
> > > supported by some RAD tool, at least something like Glade.
> > > I still remember how powerful Borland's tools were for building simple database
> > > apps back when I developed on Windows-For-Workgroups (gawd!).  At this point on
> > > Linux the OpenOffice form builder and database connectivity is the closest thing
> > > we have.
> > > 1.) Define a connection
> > > 2.) Define a query
> > > 3.) Make a "form" (or screen whatevver) , attach it to a query
> > > 4.) Populate the form with widgets attached to query elements.
> > > Lots of fancy stuff is nice, but the above satisfies 8 out of 10 situations (in
> > > my experience).
> > >      
> > Its not quite that easy for building DB RAD tools. Inter-form 
> > relationships, inter-widget relationships, cross dependencies of both 
> > widgets and data, cause and effect on user actions, callback functions 
> > and when to call/not call callback functions, dealing with datasources 
> > that cover many tables, data validation, default values (always more of 
> > a nightmare than you expect), and then making sure the data on the 
> > screen is upto date with whats on the database and vis-verser.  The 
> > whole web post/get thing is so much easier data model to work but its 
> > these kinda features most users demand of there databases. Maybe i need 
> > to code less and sleep more. Coffee is evil. Anyway point is that you 
> > have a limited use for software if you can only do as good as what you 
> > can do on the web.
> >    
>
> I'm not talking about web forms;  but functionality provided by a RAD to
> a very-long-time-ago.  The reason to move from a Web to a Client
> interface is often simple one of speed and data-density (it is easier to
> pack more on a Client window than arrange sanely on a web page).
>
> Even OOo handles inter-form relationships, detail views, etc...  but
> firing up an office package to provide a form seems like whacking a fly
> with an anvil (although CPU & RAM are so cheap these days I'm pretty
> close to just not caring anymore).
>
> I understand about the complexities, the joy of callbacks, data
> validation, etc...  I'm currently writing an OpenGroupware client for
> GNOME, yikes!  But solving many basic needs will attract, I suspect,
> more inertia and interest making the ugly plumbing easier.  One of the
> most frequent complaints about the Linux Desktop that I hear is a lack
> of an Access equivalent.  Currently what OOo provides is the nearest
> thing (that I know of).
>  
Sorry, I can be a bit permissistic when it comes to databases,
What you think is 90% of the work turns out to be 10% of the work.
Forms are never as easy as they seem. It be good if OOo could read .mdb 
files.  Maybe in a 3 years we can all have everything sorted. 

> If someone hasn't checked out the forms system in OOo they should take a
> look just to see it, for potential inspiration if nothing else.  It does
> linking of subordinate forms, detail views, etc...
>
> BTW, Does bond use GDA now?  Last I looked at it it was for pgSQL only.
>  
It uses gda for backend . but i havn't ported the data dictonary over 
yet and that runs postgresql specific queries so if you use gda it does 
bad things when you run your app. Hopefully next release will have gda 
support sorted.
I wanted to keep it userbase small until i got a lot of core things sorted.