Design Docu - Archtitecture

John Ralls jralls at ceridwen.us
Sun Sep 28 13:26:36 EDT 2014


On Sep 28, 2014, at 9:58 AM, Carsten Rinke <carsten.rinke at gmx.de> wrote:

> Hi John and Christian,
> 
> Thanks for the feedback. Happy to see that you read and even edit the page.
> 
> -> Also, controllers are the code that interacts with the model to change data. It need not be GUI: E.g., importers are controllers.
> 
> Glad to hear this. I was guessing so, but did not dare ...
> 
> I have removed the engine part and if I get the message right this section should actually go back to the goals chapter as it hasn't really been followed up so far.
> It also means that I would like to drop this topic because I would rather like to document "what has been done until now" instead of "what should have been done".
> 
> -> the current implementation is a mess with pieces of each component intermingled and spread throughout the code-base
> 
> Well, that might be the true, but I prefer not to put it like that in a "what has been done until now" docu :-)

Why not? The point of the document is to help new developers get their heads around the current code. The fact that you can’t depend on code being where it belongs is an important tip.

> 
> Maybe we can go bottom up.
> 
> What data objects are there that would be part of the Model if the MVC had been adhered to?
> Or is this all capsuled by QOF? Could we say QOF is the Model?

No. QOF has some bits of the model. It’s original purpose is the query mechanism, which is more glue than model. Other glue bits are QofObject and QofCollection. There are basic datatypes in there, too: GUID, gnc_numeric, gnc_date, as well as QofSession and QofBackend which handle loading and saving. The model bits are QofInstance, which is the base class of all of the first-class Model classes, and QofBook, which is the container class for a set of accounts.

All of the other first-class model classes’ headers are in src/engine, but not all of the code which directly writes their data is. To find it all you have to start with a GUI item and trace the calls that implement a particular behavior. You’ll find pieces in app-utils, business, core-utils, gnome, gnome-search, gnome-utils, register, and scm. Not all of it is in C.

The first-class Model classes are the ones that are persistent, and the easiest way to identify them is by looking at http://wiki.gnucash.org/wiki/SQL, especially the ERD that’s linked there. The ERD captures most of the KVP structures that are stuck on to various classes from “outside” code, which the SQL page doesn’t.

Regards,
John Ralls




More information about the gnucash-devel mailing list