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/
pgpYXD0fwQYnS.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
