I do understand your point of view, but my idea is to get results out of
the door. Doing everything right will be a lot of work, and I'm not
prepared to do it all. At least not now.
The current code has a lot of things implemented, and with several bug
fixes and with 50-100 additional lines of code I achieved the following:
1. import of gncCustomer, gncAddress, gncInvoice, gncEntry and Account
2. referencing between the the imported objects so that all of them are
connected - i.e. the addresses belong to customers, the entries belong
to invoices, the owner of the invoice is a customer and each entry
references an account
The referencing between imported and target book is not complete, so all
of these have to be imported in one file. But it WORKS.
I'm preparing patches now, in case someone finds the code useful. If you
choose not to import all patches, you can import only the bug fixes and
the correct code, and leave the code that is some kind of hack out. Thus
it could be at least partially integrated into gnucash.
The code really has a lot of issues, and is far from ready, so this
really is a distraction for 2.0. Thus I'll submit some entries in the
bugzilla with the patches attached, so that they can be handled after
2.0 is out of the door.
Derek Atkins wrote:
Georgi Mirchev <[EMAIL PROTECTED]> writes:
It turned out that I just can't use the same parameter for the invoices.
The "owner" param returns gncOwner object, and is used by the rest of
GnuCash, so nothing can be changed here.
Instead I added "owner-qof" that is of type QOF_TYPE_CHOICE, and works
with entities. It works fine with customers, and will work fine with the
other 3 objects that can be owners of an invoice. The import of
customers/addresses works fine now.
I still don't think that's the right answer... I have no objection to
changing the definition of a GncOwner (although you DEFINITELY need to
be careful about how it's done, because if done "incorrectly" it will
take a LOT of effort to change the code everywhere where it assumes it
knows how a GncOwner is implemented).
I'm working on the collections now, so that I can import the invoice
entries. In order to get any entries in, I had to add a kludge. The QOF
iterates over all parameters of the imported object, calling their
getters and trying to determine the time. Guess what happens when the
getter doesn't actually return an entity, like in the case of parameter
that is of type gncOwner. So the QOF book merger code now checks
specifically for "gncOwner". Kludge, but works. Unless we add additional
param flag "has QofInstance", so that it is compatible with QOF, or we
add dummy QofInstance to gncOwner, I can't see how to resolve that.
... and this is DEFINITELY not the right answer. We shouldn't
special-case anything inside QOF.
There is an issue that seems to be a little more complex. During the
merge of two books the entries from the first are "copied" into the
second, then the first book and it's entries are destroyed. The problem
is that the "copy" often is just pointer copy. The reason is that
although we have clone functions in the gnc objects, the QofObject
doesn't specify a 'clone' callback, so QOF cannot clone any objects. I
think this needs to be added, so that QOF can safely clone an object
whenever needed.
What do you think?
I think, as Chris said, that these APIs are only half baked and really
require a lot of thought and effort to make work correctly. I would
recommend you sit back and come up with a reasonable design before you
jump head-first into coding it up. come up with a page or two
describing how you think it should work. Be detailed, but not
loquatious.
Once you have a design we can talk about the merits, work that out,
and then you're welcome to go full-bore into it.
Keep in mind that we're really trying to get 2.0 out the door, so
don't expect many cycles on something like this which really is a 2.0
distraction.
-derek
begin:vcard
fn:Georgi Mirchev
n:Mirchev;Georgi
org:Mirchev Ideas Ltd.
adr:;;Golash 18;Sofia;;1111;Bulgaria
email;internet:[EMAIL PROTECTED]
title:Manager
tel;work:+359-2-8705566
tel;cell:+359-888-518932
note;quoted-printable:Services:=0D=0A=
=0D=0A=
Software development=0D=0A=
Web development=0D=0A=
Web design=0D=0A=
Intranet solutions=0D=0A=
Consulting services=0D=0A=
Application security=0D=0A=
Hosting solutions=0D=0A=
Software outsourcing=0D=0A=
url:http://www.mirchevideas.com/
version:2.1
end:vcard
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
