Logic ideas - 5 levels.

Tue Sep 27 06:56:29 EDT 2005

On Tuesday 27 September 2005 2:21 am, Josh Sled wrote:
> I guess as an extended optimization, some rules could be translated into
> a version appropriate to a particular backend for efficiency or
> whatever.  But I think that basic layering requires us to having these
> rules defined well above any particular backend.

Agreed. Most would be at entity, collection or book level.

> > I'm thinking of a cascade implementation - rules in the higher levels are
> > only executed if lower level rules report success.
>
> Yeah... I too want to understand how to build software as a set of
> layered constraints, type-definitions, and logical inferrences because
> of formal rules.   We can simply declare the application -- albeit
> fairly rigorously -- and have the runtime built from that declaration.
>
> But the fact of the matter is that this isn't yet an accepted way to
> build software, and there are a lot of unanswered questions about how to
> do so.
>
> More importantly in this forum: I don't want gnucash to be the sandbox
> for this effort.

Neither do I - I'm not sure that we have to.

> > Also, each user operation decides which levels of logic need to be
> > checked. In a dialog, losing the focus on one input box can utilise
> > different logic to a clicking a radio button in the same dialog. Enabling
> > "OK" would normally require most if not all levels to be checked, but
> > results should be cached so that each rule is only executed once for each
> > relevant data change.
>
> I don't doubt this is generically possible; once the set of constraints
> that allow editing-completion are satisfied by the current state of
> user-entry, a rule would be allowed to fire which would enable the
> Ok/submit button...
>
> But I believe the question with all UI stuff is: how do you make it look
> and feel reasonable?  It's easy enough to come up with generic
> grid-layout field editors, but they uniformly suck.

I don't expect the dialog layouts to be changed to conform to some generic 
layer or template. If a dialog uses a disabled OK, the support will be there 
to enable it using the logic. If not, it doesn't have to implement it. As far 
as the current GUI is concerned, some extra logic may become available but I 
aim not to force it on anyone. It's a case of abstracting that logic so that 
it can be re-used - I don't want to change the logic itself.

All the logic will happen outside the UI code itself - the UI should be free 
to represent itself as it sees fit. I don't see a need for generic layouts.

I think you're looking one step beyond where I want to go. It's about keeping 
BOTH UI's happy with the same logic, not changing either UI to conform to 
some notion of a generic interface. Separating the logic from the interface - 
to me - means keeping the existing interface but relocating the logic behind 
it.

> (In fact, the SX objects don't have *any* QOF support, which is a major
> failing that needs correction before a backend switch.)

I know, cashutil development will help me identify how that can be solved.

> > a single
> > model that can load the rules for SX or Account as required.
>
> I'm not aware of a simple, well-accepted pattern of how to do this.  I'd
> rather we figure that out -- perhaps in prototype -- before modifying
> the system to try to support it.

Agreed. Although the logic is not related to QOF and won't be part of QOF, 
some support for the logic will be required in QOF and I suspect a similar 
approach could be available via QofObject or QofClass.

In effect, the UI will query the logic for the rules that relate to the 
QofObject. The objects are best placed to understand their own logic 
requirements so, to me, it's natural to extend the object so that we can 
retrieve the relevant rules just from the QofEntity->e_type.

I want cashutil to provide this prototype because it can be modified without 
changes to the gnucash codebase. 

Note that there is a QOF requirement for accessing logic: when merging books 
or operating on data using QOF, the logic must be implementable. That means 
that whereas now the GUI calls a function in Account.c, it will need to call 
the same function via a generic interface, passing a (QofEntity*)account. 
CashUtil is a pure QOF application and it will use QOF to access this logic 
in order to provide extensible code. Adding a new object will also add it's 
logic, even if the UI does not implement a specific interface.

This is how the logic is to be separated from the UI. The checks and balances 
in the current GUI code will be relocated, often to the object itself, and 
made available to any process that registers that object.

> > I do want CashUtil to be a full CLI interface for all GnuCash data that
> > can be represented in a CLI.
>
> We already can't support our own codebase; we shouldn't make it worse;
> we have to figure out how to make new features have a UI in both the
> cashutil and gtk/gnome frontends for *free*, or at least next-to-zero
> cost.

That is the target for the logic layer, yes. However, I don't think it goes 
any wider than that. It's a new way of setting out *elements* of application 
logic, not necessarily a whole new way of writing applications.

There will always be some logic in the gtk/gnome frontend that isn't in 
cashutil and vice-versa. All I want is the critical elements of the financial 
logic in a form that is independent of the UI.

I see the layers as follows:

User Interface (Gtk/CLI)
Object&Logic Layer
QOF
(More backends via libgda)

This is working from the approach of separate packages at the distribution 
(apt-get / emerge) level.
i.e. The user could choose to install either or both UI which would depend on 
the object+logic layer and QOF. In the future, QOF will support installable 
backend modules that work as plugins.

I'm working with libcashobjects (and libcashbusobjects) in cashutil and this 
would be extended by adding code to each object to support it's own logic. 
Additional code for the remaining logic would also be in the same layer so 
that it can be easily shared with cashutil as a package upon which GnuCash 
and CashUtil both depend. In turn, the object+logic layer depends on QOF.

> I know that this is your stated goal in this thread, too... but frankly
> I don't see it happening.  I don't think it's just "lets toss some ideas
> around, and yea it's big...".  I think it's a fundamentally different
> way to write software with a lot of unanswered, hard questions.

I don't see it as such a fundamental change and I am reasonably confident that 
it can be done. I think you're looking too a wide a perspective. Maybe it 
will pan out into a whole new method - right now it's a series of tasks where 
I'll be trying to implement GnuCash logic in cashutil in a form that is 
UI-independent. 

-- 

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/20050927/3ca733b2/attachment.bin