On Thu, 2005-09-08 at 22:40 +0100, Neil Williams wrote: > 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.
Maybe. It's certainly a misnomer to call it "ancillary"; I'd consider it the majority of the value of the codebase. As well, I'm not sure that it should move into a single library, and especially not a single directory. Similar to the existing engine or business module, the logic around a type (accounts, invoices, &c.) should live close to the type-abstraction itself. 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. 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. 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... So, there's logic there. But it's not as easy as moving it into a "logic" dir. I've been thinking we'd generally "clean this up" in the 3.0 timeframe, and maybe not all at once. 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. > This is the extra layer that was discussed here some time ago which will > allow > CashUtil to behave in a manner that is consistent with the logic currently > deeply integrated into the GnuCash GUI. Given the differences between CashUtil and the Gtk frontend, I'm not sure if this is easily possible. > 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. 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. > 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. 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. ...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