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 [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
