[gnome-db] What DWI does [was Re: GnuCash page on GO site]

[Andrew Hill]

ok i'm gonna comment cause my projects are very similar to Lina's and 
i've run into similar problems to building the nessary tools to rapidly 
develop database applications for gnome. 

My approach is very similar but silighty different.
developer builds sql database. (currently only postgresql fully 
supported, libgda and mysql very partial support)
glade xml is used to generate bond xml (http://bond.treshna.com)
developer adds in sql statements and attachs code they want to app.
reports can be written in papyrus (http://payrus.treshna.com)
database application front end ready to go and can be deployed.

On Mon, Mar 01, 2004 at 10:17:18AM +0100, Rodrigo Moya was heard to remark:

>>http://dwi.sourceforge.net is the object framework I'm planning
>>on using for the future gnucash core engine.
>>
>>    
>>
>what are the advantages of this over libgda?
>could you ellaborate more please?
>  
>

This is a different to libgda.  dwi and bond are more higher up 
interfaces than libgda.  libgda requires writting code, and you'll often 
find yourself repeating the same tasks over and over again like 
inserting and updating sql statements, dealing with default values etc 
when you build a large db app.  libgda is a lot more powerful in some 
ways cause its lower down but if you want to write a huge app in a short 
amount of time its quicker and easier to manage your database objects 
and forms as one in  glade and xml etc.  It comes down to what type of 
application your writing/best tool for the job.

Though doing things this way has its fare share of problems.  One 
problem is is windows arn't related to tables in sql statements but 
widgets are. and widgets will contain other widgets and relationships 
between widgets will dicate the relationships between records.  There 
are instances where a series of sql statements need to be run on records 
that dont exist in back end yet. (ie your filling in a record, it needs 
to default a bunch of fields based on what you typed in other fields in 
a record that has yet to be inserted into db).  It can also get messy 
dealing with readn and write caches from sql. Esp in multi user 
envoriment. Another issue is validating sql before it is excuted (ie is 
this a valid input for this field type, were any charatcer limits set or 
filters, is this suppose to be unique inedx key etc). and the other 
tricky thing is dealing with complex user interface rules where the path 
you take on a form is based upon partial user input. (ie if use enters 
in account code in this field, either bring up record or add new record 
with that account code or a search box that would search different 
tables and show the results all in one gtktree based upon what type of 
data you entereed like dob, last name, or account code).  A lot of these 
problems may sound simple but they get hard when you try and simplify 
them down to a level where they can be handled at run time by a common 
routain instad of dealing with them at development time.
i'm trying to develop a html front end also as a drop in alternative for 
gtk... thats a whole new level of trickness.

Certain sql langauges are a real pain to support. I keep getting myself 
in a position where i need constraint relationships, forign keys, 
default values tied to triggers, been able to know all field attributes 
in advance etc and i'm going ikk how am i suppose to make this work 
under mysql etc. and thats one of the reasons i've always had problems 
supporting libgda because libgda in a way supports the lowest common 
demoniator.  not saying it does cause it does have a lot of useful 
functions. just a few little gaps that make it difficult to use. 

GObject isn't actually to bad and would work well, i like its way of 
doing things. I just happened I started a while ago and used my own 
class objects back then and continued to use them.  my only grips with 
it is it needs improved way of managing lots of gobjects (object 
relationships, type of objects, searching across objects, recusive 
parsing of objects etc though it could be my own lack of understanding 
here)  in regard to dwi libgda object inside a gobject would work though 
proberly not as cleanly as liked.

regard to gnomedb and gtk. gnomedb has some widgets that are supreror to 
the normal gtk ones but if your using your own database objects, not 
libgda its hard to populate them.  And a GtkEntry is so simple its 
nice.  Though I gotta at some stage embedded gtkcombo and gtkentry boxes 
into gtktree/list widgets and have it update my database objects, 
gnomedb is way ahead of me on getting this done.  Ulimtinatly i think it 
would be good to merge my bonddb objects and libgda objects so i can use 
there objects though i've start putting client side searching, sorting 
filtering abilities into my db results which may not be in libgda yet.  
Anyway back to point, libgnomedb is an extension gtk. When it comes to 
representing straight sql results and direct table data entry its very 
good. its the other stuff in the data base front end forms that becomes 
tricky.

Ok i think i done enough rambling for moment. sorry to harase so many lists.



Linas Vepstas wrote:

>Well, for starters, and this is no mean fact, I am more familiar 
>with DWI than with libgda.  That alone makes it easier for me.
>Let me provide some history.
>
>Originally, I developed DWI as a 'rapid application development'
>platform, so that I could quickly code up some complex data-driven
>apps for a client (The system monitored some industrial controls,
>and kept maintenance records for them).  Think of it this way:
>
>Suppose you wanted to develop 'bugzilla' from scratch, but 
>you wanted it to have a gtk/gnome (glade) interface, and you 
>wanted a generic sql backend.  This is kind-of what I needed 
>to do.  Instead of coding from scratch, I realized that there's 
>a generic abstraction:
>
>A window full of widgets is "kind of" like an SQL table with one
>data record in it: that window has a unique name (which
>is like an sql table name) and the widgets all have unique 
>names (kind of like sql column names).  Those widgets have 
>values that can be "read" or "written", just like the 
>columns in an sql table can be "read" or "written".
>
>All I needed to do was to write an abstraction layer that made
>sql tables and windows with widgets look alike, and then 
>just-plain copy between as needed.  So for example:
>
>pump_maintenance (repairdate, action_taken, cost, notes) 
>
>was both the abstract view of an SQL table that stored this
>info, and the abstract view of a glade-designed GTK window
>that displayed this info.  
>
>libgda seems to do something like this, but it only does it
>for sql-like data sources.  It does not do it for gtk widgets
>or glib gobjects.
>
>That was version 0.1 of dwi.  
>
>For version 0.2, I realized that what I had really written was 
>generic system of shims between different types of object systems.
>I could define an 'object' in a very easy fashion, just by
>listing a table name and some field names, and the system could
>then read/write, get/set values for those objects.   
>
>It also provided the set of utilities I needed: a way of filtering
>data before using it (e.g. format conversion), and a set of 
>abstract, generic triggers (if user pressed button, then copy
>data from widget to sql, etc.).  Most importantly, it allowed 
>me to work in a declarative rather than proceedural fashion.
>As a finaly advantage, its very small and very light weight 
>for what it does: its maybe 5KLoc of code.
>
>Now, I could argue that some of these DWI features should be
>incorporated into glib gobjects, except that gobjects are 
>already way too complicated and hard to understand.  Similarly,
>maybe some of this should be put into libgda: but ...
>
>Suppose I approached the glib gobject folks, and told them that
>they should merge gobjects with libgda.  Everyone would think
>I'm crazy, and they would say no.  So why should I bother? 
>After all, I've already got a small, simple, easy-to-use 
>library that merges gobjects with sql, and it does it in 
>the way that I want it done.  So that's where I currently stand.
>
>Re: the gnucash engine: I was planning on using DWI to provide
>the shim that would translate the gnucash objects (including
>the business accounting objects) to the database, and back.
>The idea of using dwi would be that it would then become very
>easy to add new types of financial objects.
>
>Its possible that maybe I could use libgda for this instead;
>however, I'm concerned that gnucash uses a number of fancy
>constructs, and so it would be impossible without hacking 
>the guts of libgda.  Worse, these hacks might not be accepted
>as patches by the libgda developers.  So what was originally
>a few weeks of coding suddenly turns into 6 months of 
>arguing on the mailing lists; its a high-risk path for 
>something that should be small, simple and easy. 
>
>
>--linas
>
>  
>