Design Docu - Archtitecture

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Design Docu - Archtitecture

Carsten Rinke
Hi,

I made a first step in updating the documentation of the GnuCash
Archtitecture:
http://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Introduction

My idea is to go through the "old" chapter of Architectural Goals and
transfer parts of it into this "new" chapter where these goals shall be
described as facts. Goals that are no facts remain in the "old" chapter
(unless these are no valid goals anymore).

Every now and then (and probably in small steps) I will come back here
to the mailing list to double check my understanding and to get hints
whether I am thinking totally off track.

If what you see in the link above is somewhat hitting the truth, I would
continue drilling down into the Model (and then come back again).

Is it somewhat hitting the truth?

Kind regards,
Carsten
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Design Docu - Archtitecture

Christian Stimming-4
Hi Carsten,

thanks  a lot for going those next steps towars some architecture
documentation that is really worth its name. By now I've also found enough
motivation to start to add my own edits in those texts. I've just modified
your text from the original texi documents and added a bunch of statements to
describe the deviation of the current source code status in comparison with
the original (lofty) goals.

In fact the original text is only in parts helpful anymore. The original text
stated "the engine" is some single instance that does the coordination between
the model and the view. Unfortunately there is no single instance that does
this described coordination, and it is also not called "the engine". What do
we do with this section in the text...?

There is some coordination between the model and the view through the
qof_event framework, in particular any create/update/delete event of Account
or Transaction. There is also some coordination between the model and the view
through the g_signal's that are sent between various g_object's involved, but
I don't know any details here. Clearly both are useful concepts, but
conceptually those are "just" part of the "Controller" concept, not of some
extra instance that might be called "Engine" or whatever.

The name "the engine" in current gnucash IMHO just refers to the content of
the src/engine directory. This in turn IMHO contains a bunch of different
things, such as the majority of the major data structures (but clearly not all
- src/libqof contains the rest) and some guile - C wrapper issues, and some
whatnot thingies. Maybe the description of the gnucash architecture should
rather start with those different modules? I don't know, too.

Regards,

Christian



Am Samstag, 27. September 2014, 22:14:03 schrieb Carsten Rinke:

> Hi,
>
> I made a first step in updating the documentation of the GnuCash
> Archtitecture:
> http://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Introduction
>
> My idea is to go through the "old" chapter of Architectural Goals and
> transfer parts of it into this "new" chapter where these goals shall be
> described as facts. Goals that are no facts remain in the "old" chapter
> (unless these are no valid goals anymore).
>
> Every now and then (and probably in small steps) I will come back here
> to the mailing list to double check my understanding and to get hints
> whether I am thinking totally off track.
>
> If what you see in the link above is somewhat hitting the truth, I would
> continue drilling down into the Model (and then come back again).
>
> Is it somewhat hitting the truth?
>
> Kind regards,
> Carsten
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Design Docu - Archtitecture

John Ralls-2
In reply to this post by Carsten Rinke

On Sep 27, 2014, at 1:14 PM, Carsten Rinke <[hidden email]> wrote:

> Hi,
>
> I made a first step in updating the documentation of the GnuCash Archtitecture:
> http://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Introduction
>
> My idea is to go through the "old" chapter of Architectural Goals and transfer parts of it into this "new" chapter where these goals shall be described as facts. Goals that are no facts remain in the "old" chapter (unless these are no valid goals anymore).
>
> Every now and then (and probably in small steps) I will come back here to the mailing list to double check my understanding and to get hints whether I am thinking totally off track.
>
> If what you see in the link above is somewhat hitting the truth, I would continue drilling down into the Model (and then come back again).
>
> Is it somewhat hitting the truth?

Carsten,

It appears you’ve confused view part of the Model-View-Controller pattern [1] with database views [2]. More than one MVC view can represent a single database view: Consider a transaction that you are looking at in two registers. It’s the same data, but the presentation is different because each account has a different viewpoint about the transaction.

Also, controllers are the code that interacts with the model to change data. It need not be GUI: E.g., importers are controllers.

If you look at the diagram in [1], you can replace “User” with GUI, since it both presents views to the user and receives the user’s commands to pass back to the controller. This is actually a good implementation as well because with suitable shim classes it makes it much easier to use more than one GUI, something that’s necessary for accommodating both normal computers and “mobiles” like phones and tablets.

As Christian points out, “the engine” is a bit fuzzy in the current code, but it certainly isn’t a layer between the model and the view or controller. Probably best to leave that out of this level of the discussion. I think I’d mention MVC with the wikipedia link and say that that’s where we want to go, but that the current implementation is a mess with pieces of each component intermingled and spread throughout the code-base.

Neither we nor any of the database backends we contemplate using support 2 phase commit [3]. Databases generally implement atomic commit [4], but we’re not using that feature in the SQL backend yet, and the XML backend is an all-or-nothing save driven by a timer or the user. The persistent classes currently implement a half-hearted effort at atomic commit but in general will fail catastrophically if anything goes wrong.

Regards,
John Ralls

[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] http://en.wikipedia.org/wiki/View_%28SQL%29
[3] http://en.wikipedia.org/wiki/Two-phase_commit_protocol
[4] http://en.wikipedia.org/wiki/Atomic_commit
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Design Docu - Archtitecture

Carsten Rinke
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 :-)

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?

Kind regards,
Carsten

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Design Docu - Archtitecture

John Ralls-2

On Sep 28, 2014, at 9:58 AM, Carsten Rinke <[hidden email]> 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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel