r20616-20630 (GncOwner)

Nicholas Manville manville at doctors.org.uk
Sun May 15 04:58:31 EDT 2011


On the particular point about accounts vs tax lines i wonder if it would be better to have a seperate class of 'tax objects' which could reference accounts and/or individual transactions. And then these objects have US or or other territory subclasses. Otherwise, as you hinted at, we could end up with significant fragmentation and duplication of account data and functions and it is unlikely a tax rule will effect how an account interacts with it's transactions within the code base, merely how the account is reported at a different phase. An account could hold references to all the tax-objects of account sub-class that reference it with a maintenance function during any commit phase to keep them congruent. 


-----Original Message-----
From: Phil Longstaff
Sent:  14/05/2011 21:33:27
Subject:  Re: r20616-20630 (GncOwner)

On Thu, 2011-05-12 at 13:49 -0400, John Ralls wrote:

> Geert, I was actually thinking from the data model view rather than the
>  accounting view, but ideally the data model closely reflects the
>  problem domain, so they're not dissimilar.
> 
[OpenERP - deleted]

> But more broadly, Gnucash is supposed to be an object-oriented design,
>  so that all of the common elements are provided by a superclass and
>  any additional specializations (like the pointer to a shipping address
>  for a customer) are provided by a subclass. (That single
>  characteristic is the fundamental flaw of the KVP design: Because KVP
>  data are added to objects outside of the class interface, inheritance
>  and polymorphism are broken.) The goal of the transactional
>  refactoring is that the GUI will be able to request from the backend
>  only the objects it needs to display, to lock only the objects it is
>  editing, to commit the changed edits as a logically atomic commit --
>  and to have the whole edit atomically rolled back if any part of the
>  commit fails. In order for that to work, objects must have control
>  over all of their member data and be able to serialize it to a
>  standard interface that an arbitrary backend can store and retrieve.
>  That was the original design goal stated for QO!  F, BTW, but
>  gnucash's implementation of QOF has destroyed that ability and
>  gnucash's use of QOF is inconsistent.

[ there are a bunch of GUIs - deleted ]

> Those two goals motivate my refactoring plan: Make everything in QOF
>  into a class hierarchy with separation of classes by functional and
>  data responsibility and all in the same class system (meaning GSEALED
>  GObject, C++, or Python -- each  of which has advantages, so which one
>  we use is open for discussion, and that discussion can be put off
>  until we have complete unit test coverage in QOF), then refactor
>  Engine, Business Core, and Backend into derived classes from the QOF
>  superclasses. That's the model part of MVC. After that (or in parallel
>  if someone else decides to work on it) we need to ensure that all of
>  the combining of those model objects for presentation to the user and
>  for handling edits (For example, posting an invoice will need to read
>  objects of the Customer, Invoice, Transaction, Split, Account, and
>  Commodity classes, with a write lock on Invoice, Transaction, and
>  Splits) is handled by another set of classes, so that the GUI and API
>  can concern themselves only !  with user interaction.  

This all sounds great and I'm wondering what the steps are.  One
original idea behind KVP is that modules can be added to gnucash and can
associate data with the core objects.  An example is a US tax data
module which associates an account with a line on a tax form.  Should
this tax line become part of the Account record in the db?  Might be OK
for US users, but what if a user from a different country needs more
information or different information.  Do we want Account, and
USTaxAccount and OtherCountryTaxAccount derived from it?  What about
other relationship types?

I think it would not be difficult to pull the info currently in slots
out of them and into better data structures which have their own tables.
They could be attached to the main core objects so that they load/save
at the same time but would be independent and in their own tables.  Does
this idea help with your refactoring?

Phil

_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



More information about the gnucash-devel mailing list