GNOME.org
 

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

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]