On Thu, 2005-09-08 at 22:40 +0100, Neil Williams wrote: > On Tuesday 06 September 2005 11:33 pm, Derek Atkins wrote: > > > Quoting Neil Williams <[EMAIL PROTECTED]>: > > > A further distinction the follows as the ancillary logic expressed in the > > > current GUI is abstracted into the common libraries for CashUtil and > > > GnuCash to use together. So finally the common libraries include the > > > objects, the backend and the logic. > > 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.
At the moment I know of no logic in the GUI that is not also enforced in the engine. These reason that these checks have been embedded in the GUI code to enhance the user experience by providing immediate feedback. For example, a "bank" account must have a name and be denominated in a currency not a stock. The account creation code in the engine should enforce this (I have no idea if it does), but there's absolutely no reason to wait until the user has filled out the entire dialog and clicked the OK button before informing them about these restrictions. It should be integrated into the dialog the user is filling out. For example, the OK button on the dialog should not be enabled until after the user has entered an account name. As far as I'm concerned, Gnucash needs to do more of this, not less. > This is the extra layer that was discussed here some time ago Got a pointer? > 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. Why would you want to allow incomplete objects to exist in the first place? All the required parameters for an object should be supplied with the object is first created. Cashutil doesn't accept multiple parameters at the same time? E.G. "create account type bank currency GBP parent xyz"? That command should give you an object that passes the integrity checks for an account. All other account fields are optional and can be checked when they are added. > 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 have no problem if you want to add validation functions for objects, but I will object to any changes that make the GUI less responsive to users. > Some ideas on code are here: > > http://code.neil.williamsleesmill.me.uk/cashutil/logic.html > > Objects could register their own logic handlers, applications could register > a > logic handler for a particular QofBook. The handlers would be called only > when the user indicates that s/he considers that the edit of that object is > complete - by clicking OK in a dialog or typing 'commit' in the CLI. If the handler is capable of eliciting more data from the user, then you need two handlers. One for Gnucash and another for Cashutil. How is this any different that having the logic in the GUI and also in the cashutil cli? If you want consistency the handler should only validate the object, not validate it and try to elicit missing information. If the object isn't valid the handler should return an error code to indicate failure (or an bitmask to indicate what failed). Leave the eliciting of data to the appropriate UI code. David _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
