Implementing Business Module: advice needed

[Bill Gribble]

On Wed, 2001-11-07 at 11:23, Derek Atkins wrote:
> I'm trying to come up with a solution that is both simple to implement
> but also simple to maintain.  Similarly, it would be nice if the
> business features were optional.

IMO, business features being optional is mandatory.  Most users of
gnucash don't want them... not in a passive "I don't have desire for it"
way, but in an active "I have a desire for it not to be there" way. 

> The most obvious way to implement this would be to extend the engine
> to directly know about all the various new objects that I plan to
> implement.  The problem with that approach is that it doesn't scale or
> expand very well.  In particular, if you want to add new business
> objects later, you have to add them into the engine.

Not if you do it correctly.  what does it really mean to "add a new
business object"?  There's no law that says all the entities that are
known about have to be enumerated in a file somewhere.  The combination
of smart partitioning of information flow and an extensibility mechanism
(which you may need to implement hooks for to make this work) should do
the trick.

Let's take an example; say, a customer database.  What do you need in
order to implement this?   In the most basic case (where no info flows
from the customer DB to the rest of the app), 

  - you need a dialog to view and edit the database.
  - you need some API for the dialog to use to edit the database 
  - you need a database. 

Well, if we assume for the moment that the "business module" requires an
SQL database on the backend, all you need is some widgetry for the
editor and a few C files in a gnc-module.  When the module is loaded
it can poke a menu item to open the editor into the app's menus. 

Now if you want to connect the customer database to the existing Gnucash
data structures, just use the KVP tables to store the GUID of a Customer
record in the relevant Transaction.  You'd need to do a little more
widgetry to allow this part of the transaction to be viewed and edited.

The engine doesn't need to "know" about this stuff in the sense of
having compiled-in API or data definitions; the only tricky part is
making the register show it.  Dave has been working on a lot of
customization features for the register which should make it moderately
straightforward to do this. 

> The biggest issue is that while the UI is fairly modularized, the core
> engine is not.  This means that the core needs to know about
> EVERYTHING.  I don't mind implementing my list of objects inside the
> engine, but I'm not convinced that it's the _right thing_ to do.

I recommend against it.  There may be certain critical features that
need to find their way into the engine, such as a way of allowing
modules to customize things when they are loaded, but I think that
number will be small, and those things will be more generally useful to
gnucash as a customizable app. 

Remember that the "engine" is what most accounting programs call  the
"General Ledger" combined with the "Chart of Accounts".  Invoices, sales
orders, customers, etc etc are all top-level modules just like the
general ledger.  You don't need to stuff everything into the engine.

Let me suggest that you grab a copy of "Peachtree for Dummies" or
something similar just so you can see how the popular packages do this
stuff.  That's not necessarily the way WE want to do it, but it's
someplace to start getting an idea of what's required. 

b.g.