What DWI does [was Re: GnuCash page on GO site]
- From: linas linas org (Linas Vepstas)
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Linas Vepstas <linas linas org>, Charles Goodwin <charlie xwt org>, Derek Atkins <warlord MIT EDU>, gnucash-devel gnucash org, Josh Sled <jsled-gnomeoffice asynchronous org>, Gnome Office <gnome-office-list gnome org>, gtk-list gnome org, gnome-db-list gnome org
- Subject: What DWI does [was Re: GnuCash page on GO site]
- Date: Wed, 3 Mar 2004 09:45:13 -0600
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?
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.
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas linas org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
] [Thread Prev