Attached you'll find a C code example in how I can "hide" QOF from the GObject implementation in the GC's engine.
Please consider the following: 1) This is just an example and not all the methods supported for the objects had been implemented 2) This example just take three objects: the top level in the hierarchi (a GncObject), a GncSplit with more detail in methods examples and a GncAccount used in GncSplit 3) The code try to explain how this objects will interoperate: how a virtual functions in GncObject will be implemented by, for example, GncSplit 4) An interaction between the GncSplit and a poorly implemented GncAccount 5) It has a lot of erros and had'nt been tested before, just to show an example :-) For now, QofBook is required by the *new method in the objects, but realy you can miss it and set it after the object has been created for exaple (see GncObject), this isn't the final goal just a possibility to realy "hide" QOF behind... I'm thinking in create a GInterface with methods that must be implemented by a object that will be a backend for the interaction of the engine with the data, like in QofBackend; in this way the GncObject's could call methods without call directly QOF, that will be a backend (a Data Provider); this arquitecture could help in implement diferent backends but based in a pure GObject framework. -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE)
gnc-gobject.tar.bz2
Description: BZip2 compressed data
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
