QSF and qof_book_merge
Neil Williams
linux at codehelp.co.uk
Sun May 1 08:20:52 EDT 2005
> On Friday 29 April 2005 19:35, Neil Williams wrote:
> > On Friday 29 April 2005 11:02 am, Geert Janssens wrote:
> The thread I was referring to in my message actually was your thread, and
> already led me to your website, thank you :)
>
> There's a wealth of information there, and it will take me some more time to
> grok it all, and ever more time to really figure out the gnucash internal
> qof
> object structure and how to map my database structure against it. But I'm
> working on it.
Define your own objects and let the framework / external processes worry about
mapping between object types. Try out QOF-generator which will create some
test objects of your own (and write out sample QSF):
You can run it locally via Apache:
http://sourceforge.net/projects/qof-gen/
or you can create C code direct from the home page:
http://qof-gen.sourceforge.net/
It is pre-alpha - but the generated code does compile.
You won't ever import GnuCash objects directly into any program except GnuCash
- your program can load a file containing GnuCash objects but these will be
translated into your own objects within QOF - that's the code I need to
finish. The same works with your code, you don't need to export GnuCash
objects - it would lead to unnecessary duplication of QOF objects - you
export your own and then map the changes. Don't worry about the details for
now, a lot of current map code will change before it's usable.
Naturally, being XML, if there are other ways of converting the objects, those
can be used too - XSL etc. Mapping is designed for those more awkward
situations that require calculations, defines, conditionals and loops that
simply aren't supported in XSL.
> The code for my access application is all in Visual Basic (for historical
> reasons). I'm not sure if I can make VB work with QOF on Windows (right now,
> I don't understand QOF at all yet),
That is a TALL order. QOF doesn't build on Windows yet and no-one is currently
working on that. I'm sure it can be done but I can't say how long it might
take. Once G2 is out, there have been offers of porting G2 to Windows which
would have to make QOF portable as well.
> Eventually the Inventory program itself will have to be replaced with
> something on linux. This 'something' could use QOF, to ease the interfacing
> with amongst others GnuCash, but the intermediary solution should mainly
> just
> do what it's required. There is no need to be able to extend it later, as it
> is going to be replaced anyhow.
Exactly. Define your application and it's objects as YOU require for your
program. That is the sensible approach and it's the best way to get the best
out of QOF. After all, the Q is for Query and you won't get sensible queries
if the objects have to be translated all the time.
You could use QOF as the query engine of your application instead of an
external database or you could define QOF objects for structs populated from
an external database and export those.
It harks back to a previous message in these archives:
Is your program a front end to a database that can use another front-end?
or is your database a backend to the program that can use other backends?
PROGRAM or PROGRAM PROGRAM
BACKEND BACKEND DATABASE
Do you want your program to work with different databases?
or do you want your database to work with different programs?
QOF can provide data exchange in either situation but the question is central
to how you design your program.
Example:
GnuCash works with different databases. The database is a backend and it can
be replaced. This is how GnuCash can work with SQLlite, how the postgres
backend exists and how it also uses XML. One program, multiple backends.
QOF fits naturally into this scheme because it can provide a mechanism for
adding backends, such as QSF, to an existing program. This is what I've done
with pilot-link. I've added QOF to libpisock and in doing so added a backend
as well. QOF has a second backend that is in development - a GUI data mining
interface called DWI - and that will become available to any application
using QOF as a library.
Alternatively, if you take the database-imperative to it's limits, you'll be
creating a data set that can be exported to another database and use any
number of front-ends.
As QOF has no pre-determined front-end, it can work here too and by doing so,
it automatically adds more backends. In effect, it gives you the best of
both. You get an engine that can work with multiple front ends and multiple
backends, with the same data being mapped or translated between them.
(view in monospace font)
PROGRAM A PROGRAM B
|<---------------------->| |<-------------------------->|
BACKEND A1 QOF BACKEND B1
|
|<--------------->|<-------------------->|
BACKEND Q1 BACKEND Q2 BACKEND Q3
In this scenario, backendA1 is incompatible with programB which has it's own
incompatible backend, B1 that programA cannot use.
However, all programs linked to QOF can share any or all of the three (in this
example) QOF backends and adding a backend to QOF adds a backend to all QOF
programs. By mapping ProgramA objects to ProgramB objects within QOF, the
data in any of the Q backends also becomes available to both programs.
Work is under way to port the newer QOF code to other QOF applications that
use internal QOF code like GnoTime and I aim to have all QOF programs using
QOF only as an external library eventually.
There's nothing wrong with having a backend of your own, it's how GnuCash
works, as long as there are sufficient QOF objects to import/export all the
essential data.
> > QSF is an inherent part of G2. It's implemented and working. It produces
> > valid XML, according to the schema, and some export routines are now
> > present. Currently, a bug in the G2 GUI code is preventing the import of
> > QSF data but 99.9% of the required code is again, present and working.
> >
> What exactly is this bug ? I'm willing to look at it.
The Merge Druid stalls. In the G2 port, the GUI code needs to be overhauled as
it currently won't display the first page but more importantly it won't
proceed in the conflicts page.
It affects both the File->Add New Account Hierarchy and File->Import QSF.
In the new account hierarchy, the account druid runs fine and the merge druid
picks up the data successfully. Even after the conflicts have been resolved,
clicking Forward does nothing.
This worked fine in the 1.8 tree so something is definitely wrong in this
particular druid. It needs to be re-written but problems exist:
1. The rest of GnuCash uses GtkDialog but there's no GtkDruid, this druid uses
GnomeDruid instead.
2. There is a GnuCash druid template in G2 that is far more flexible but it's
not documented. My GUI skills are admittedly poor but I can't make sense of
the gnc-druid-provider code in src/gnome-utils/
My problem is that I can't see where the actual *contents* of each page are
defined - I'm almost certainly missing something obvious. (again)
> Also, do you have a sample QSF File I can use for import tests ?
qof-gen can create your own, you can also export QSF files from the current G2
CVS build. Try the Export Chart of Accounts or the Export under the Business
features (although you need to have created some invoices / customers etc.
before you'll get any data).
There are examples on my QSF website.
I'm adding QSF Export routines to GnuCash with each commit. I'm hoping to have
a export-anything-anyhow druid for GnuCash 2.1 (or possibly 2.0.1)
--
Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050501/6a6e5c91/attachment.bin
More information about the gnucash-devel
mailing list