Ancillary logic ideas

[Neil Williams]

On Tuesday 06 September 2005 11:33 pm, Derek Atkins wrote:
> > Quoting Neil Williams <linux at codehelp.co.uk>:
> > A further distinction the follows as the ancillary logic expressed in the
> > current GUI is abstracted into the common libraries for CashUtil and
> > GnuCash to use together. So finally the common libraries include the
> > objects, the backend and the logic.

The ancillary logic, therefore, does need to be moved between files - implicit 
rules in the current dialogs etc., need to be abstracted into a set of rules 
for the object and maybe the book - as a whole. This will involve remodelling 
individual functions in current GUI files to instead call a function in a 
"logic" library.

This is the extra layer that was discussed here some time ago which will allow 
CashUtil to behave in a manner that is consistent with the logic currently 
deeply integrated into the GnuCash GUI.

e.g. if an Account is created in the CLI, it is created one parameter at a 
time - it cannot rely on a usable value in another parameter. Once the edit 
is complete, the logic code can check the integrity of the instance as a 
unit, including verifying that one parameter is logically consistent with 
another.

This code is likely to use QOF processes and functions but it's not really a 
job for QOF itself. It's more a function of the objects and the application. 
I may write some new QOF code to support it but I expect the majority of the 
logic handler structure to be implemented by those applications that need it 
- GnuCash and CashUtil.

It will form a layer above the engine (QOF). The code will fit partially 
within the object layer and partially in the application space. Some of the 
implementation can happen inside the objects themselves - Account.c should be 
well suited to checking the integrity of a hand-edited Account object - but 
other functions may need a home outside existing objects, e.g. when checking 
the logical integrity of an account hierarchy.

Can I propose src/logic for this code?
Building libcashlogic.la - installed alongside libcashobjects etc. to be 
shared by GnuCash and CashUtil.

Some ideas on code are here:

http://code.neil.williamsleesmill.me.uk/cashutil/logic.html

Objects could register their own logic handlers, applications could register a 
logic handler for a particular QofBook. The handlers would be called only 
when the user indicates that s/he considers that the edit of that object is 
complete - by clicking OK in a dialog or typing 'commit' in the CLI.

It's a new look on the previous idea of a QofObject:merge_helper and would 
replace such an idea with a much more rigorous, transparent and equitable 
process. e.g. Anyone dealing with a successfully edited Account could be 
assured that the same logic is always used to check the integrity of the 
Account data. Naturally, each process can make their own checks too but the 
new code would provide a baseline. The minimum for this baseline should be 
that the object is suitable for writing out using the gnucash file backend 
and some of the assumptions in the backend can be used to enforce this.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050908/90b15ede/attachment.bin