Ancillary logic ideas

[David Hampton]

On Thu, 2005-09-08 at 22:40 +0100, Neil Williams wrote:
> 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.

At the moment I know of no logic in the GUI that is not also enforced in
the engine.  These reason that these checks have been embedded in the
GUI code to enhance the user experience by providing immediate feedback.
For example, a "bank" account must have a name and be denominated in a
currency not a stock.  The account creation code in the engine should
enforce this (I have no idea if it does), but there's absolutely no
reason to wait until the user has filled out the entire dialog and
clicked the OK button before informing them about these restrictions.
It should be integrated into the dialog the user is filling out.  For
example, the OK button on the dialog should not be enabled until after
the user has entered an account name.  As far as I'm concerned, Gnucash
needs to do more of this, not less.

> This is the extra layer that was discussed here some time ago

Got a pointer?

> 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.

Why would you want to allow incomplete objects to exist in the first
place?  All the required parameters for an object should be supplied
with the object is first created. 

Cashutil doesn't accept multiple parameters at the same time?  E.G.
"create account type bank currency GBP parent xyz"?  That command should
give you an object that passes the integrity checks for an account.  All
other account fields are optional and can be checked when they are
added.

> 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.

I have no problem if you want to add validation functions for objects,
but I will object to any changes that make the GUI less responsive to
users.

> 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.

If the handler is capable of eliciting more data from the user, then you
need two handlers.  One for Gnucash and another for Cashutil.  How is
this any different that having the logic in the GUI and also in the
cashutil cli?  If you want consistency the handler should only validate
the object, not validate it and try to elicit missing information.  If
the object isn't valid the handler should return an error code to
indicate failure (or an bitmask to indicate what failed).  Leave the
eliciting of data to the appropriate UI code.

David