Creating Gnucash invoices with XML
linux at codehelp.co.uk
Tue Apr 6 15:24:48 EDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 06 Apr 2004 1:26, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> > That's the first job, build the DTD and enforce it.
> > (abort loading of XML files that don't match the DTD structure - that
> > will need to be done by 'proper' C XML handling libraries, libxml etc.)
> So you're suggesting a re-write of all the existing XML i/o to use
> verified schema instead of the existing hand-created generators and
> parsers? Not that I'm against this idea, but doesn't that go against
> the grain of re-using the existing code?
Yes, it's a pity the I/O is one lump of code - in order to do any work on
partial files, let alone DTD's (not necessarily schemas which are slightly
different), I'd expect to have to do more work than expected on this bit.
Thereagain, IF the XML data file format is to be abandoned, this might be no
bad thing. The one good thing is that I should still be able to reuse the
bindings, getting the XML data into GList etc.
This is getting to be a much larger project than I anticipated.
> I suppose that's fine provided your plan is:
> 1) reverse-engineer the existing XML objects into Schemas
> 2) re-write the xml code to use schemas
> 3) drop rewrite in place of existing code
That would be the most flexible solution and it would open the door,
hopefully, to all imports and exports from all sections.
> I just suspect this is a lot of work for (IMHO) little gain.
I know, I'm trying hard to convince myself - don't put me off!
> But we already have the XML structures defined (albeit not in a
> Schema). Been there, done that -- reuse what we've got unless you
> really want to re-write all the i/o. But if you have limited time I
> see little reason to do that.
How soon will gnucash leave the XML data file behind? Once that's done, I'll
have a free hand to rewrite the XML I/O. The current I/O would need to be
retained, perhaps as a secondary program, for backwards compatibility?
> Honestly, if you want to implement a "gnucash XML import" I'm 100% behind
> you, and I think it's a great idea. I'm not trying to derail that concept.
> I think it's a GREAT idea.
Maybe I can do this in two stages. Work with the current I/O for now with a
view to just getting a limited XML import functioning. Then work on the
I could start by making the current I/O into a standalone file that outputs
the content in GList (much like your CSV test program) and then getting that
to accept partial input.
> >> Yes, the xml parsers need to be modified to not require a full book.
> >> Not TOO difficult, I don't think.
It'll take me a while to get to know the hand-crafted parser, I'm used to
> IMHO, yes. I think the bulk of the task is the merging. You need to
> determine what data in the import maps to the existing data, what data
> is new, and what data is a duplication. I think this is the hardest
> part. There's been a good deal of work to do this with Transactions,
> but not with Accounts, or any of the business features.
> NOTE: a general API to "merge two books" would be a good potential
I agree, but this task is already big enough for me. I'm OK in C but I'm no
> Yes. Although it might behoove you to collect all the events and save
> the applause until all the names have been called. If you've got 100
> events, would you rather have 100 pop-ups or a window with a list of
> 100 items? Personally I'd rather have the latter.
Definitely. Having just had a bad day with KPilot - offering a collision
dialog one per contact for 30 contacts - it's NOT fun!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the gnucash-devel