Logic ideas - 5 levels.

[Josh Sled]

On Sun, 2005-09-18 at 13:55 +0100, Neil Williams wrote:

> > Data-type constraints are 
> > generally above-and-beyond those provided by programming languages, such
> > as "positive integer", "bounded integer", "length-limited string",
> > "patterned string", &c.
> 
> (This will be easier once the gnc-backend-file is replaced - some of these 
> bounds can be set in the XML if schemas are used properly. QSF does this to 
> ensure that all GUID strings are true hexadecimals and integer fields do not 
> contain string characters. That provides an entry-point validation at the XML 
> level.)

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.


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


> 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'd hope that the model and the view / controller would all be single units 
> that take their parameters from the QofObject - I'd rather not have a 
> specific model for SX and a specific model for Account. Instead, a single 

Of course they're specific models ... they're different things.

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


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


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

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.

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