Ancillary logic ideas

[Neil Williams]

On Friday 09 September 2005 2:28 am, Josh Sled wrote:
> On Thu, 2005-09-08 at 22:40 +0100, Neil Williams wrote:
> > The ancillary logic, therefore, does need to be moved between files -

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

True! What would you propose instead?

Core logic? Cash logic? It's only ancillary from a QOF perspective because 
objects do not have to define any logic - e.g. some non-financial objects.

> As well, I'm not sure that it should move into a single library, and
> especially not a single directory.

Only the supporting code would go into src/logic - a lot of the specific 
validity tests are best placed within the object source itself. On 
reflection, src/engine could be suitable (once QOF is removed).

Routines that provide access to the test routines for a specific object, 
routines that make some sense of the return values.

Also, some validity tests cannot be done in the object because they are 
"inter-object" assertions and these may need a home.

> Similar to the existing engine or 
> business module, the logic around a type (accounts, invoices, &c.)
> should live close to the type-abstraction itself.

Absolutely.

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

I agree, it is not really part of the UI - CashUtil could make good use of the 
same logic.

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

This is the application-specific handler's job. It receives information from 
the object complaining about some missing data and the handler in the 
application needs to raise a dialog (GnuCash) or a printf (CashUtil).

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

Great. I'd like to help with that.

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

As above, it requires changes in various locations.

> I've been thinking we'd generally "clean this up" in the 3.0 timeframe,
> and maybe not all at once.

This is just "information gathering" on my part. I want to know what people 
think and what kinds of logic we are going to be abstracting.

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

Absolutely. Nevertheless, it is important now because it will colour how I 
plan CashUtil development. I'll be testing all this logic in CashUtil because 
we all know that as soon as users get their hands on the CLI there'll be a 
stream of messages along the lines of:

"GnuCash does X this way, why does CashUtil do it differently?"
"GnuCash doesn't accept X, why does CashUtil?"
(CashUtil is currently over-permissive but then it's not exactly ready for 
release either!)

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

I like a challenge! I thought QOF_UNDO would be hard but it turned out to be 
simpler than the merge - as far as it's CashUtil implementation is concerned.
:-)

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

Please elaborate - it is exactly these points that I need to clarify before 
working on the abstraction.

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

1. I want each QOF object to be able to benefit from validation.

2. I want validation to be object-specific where appropriate and the easiest 
way of dealing with objects in GnuCash is using QOF methods.

3. As I said, it isn't a job for QOF itself - QOF just provides some tools 
like object declarations, generic object handling and a simple means to share 
the logic with CashUtil from a single source.

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

I expect that abstracting the test from output to the user will help.

-- 

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/20050909/a564916a/attachment.bin