Ancillary logic ideas

[Josh Sled]

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

Maybe.  It's certainly a misnomer to call it "ancillary"; I'd consider
it the majority of the value of the codebase.

As well, I'm not sure that it should move into a single library, and
especially not a single directory.  Similar to the existing engine or
business module, the logic around a type (accounts, invoices, &c.)
should live close to the type-abstraction itself.


An example is the logic for computing the set of real transactions that
should be created for a particular set of scheduled transactions at
point-in-time.  It currently lives in gnome/dialog-sxsincelast.c, but
it's not *necessarily* UI-related.  Certainly there are UI issues ...
some subset of the transactions will have a user-interface dialog to
request a particular value-binding or transaction-disposition.  And
given the current user-interface flow between the pages in the
since-last-run dialog, there's some re-computation of the transaction
that occurs.  But all that can be abstracted away...

So, there's logic there.  But it's not as easy as moving it into a
"logic" dir.

I've been thinking we'd generally "clean this up" in the 3.0 timeframe,
and maybe not all at once.  There's a huge set of code changes, design
changes and reorganizations to make.  And it's certainly less important
than, for instance, the G2 port or the module-system rip-out.


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

Given the differences between CashUtil and the Gtk frontend, I'm not
sure if this is easily possible.

> 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 sounds like value validation.  I think it's best handled
declaratively, but it's pretty straightforward to do procedurally.

I'm not sure this is the hard part to abstract out, though.


> 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 don't see how this has anything to do with QOF.

There is a general GnuCash design issue about too closely coupling logic
to the UI-servicing routines.  In part because there's a really hard
problem, there.  We do make efforts to abstract GTK-specific things in
particular out, anticipating a Qt (Motif, historically) front-end as
well.

But it's especially hard when mixing user-interface metaphors...
CashUtil has a user-imperative command-loop paradigm, while the GTK
interface is a more traditional windowing-toolkit / event-driven /
dialog paradigm.  A similar problem would arise when trying to abstract
the logic to back an HTTP request/response interface.

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`