On Tuesday 09 June 2009, Derek Atkins wrote: > Josh Sled <js...@asynchronous.org> writes: > > David Goodenough <david.goodeno...@linkchoose.co.uk> writes: > >> So the question is, which way to go. Should I simply work on the old > >> QSF code and get it to work, and then add selection to it and matching, > >> or should I look at the new framework and rewrite the QSF code to work > >> there? > > > > QSF is a bad idea. Please don't propagate it. I am not wedded to QSF, I am wedded to an XML import/export which can then be trasformed using XSLT into whatever other XML format might be required. > > This is where Josh and I disagree.. I don't believe it's completely > a bad idea, but I believe the what's there is poorly done. The concept > of a generic XML that can encode and parse generic objects is a good > idea IMHO. But what's there is... limited. I agree with this. > > > Domain-specific import/export formats and import/export logic are going > > to be far easier to implement, debug and use. > > Maybe.. Keep in mind that the information in an import object is not > necessarily the same used internally. Yes, one COULD use the GNC XML > object formats for import/export, but you'd still need to recode > the I/O to handle import objects differently (e.g. lack of a GUID). Where is the GNC XML format defined? I have some ideas that I have used elsewhere to fix the GUID problem. > > > Hopefully, you can find something to leverage in the existing (generic, > > not QIF-specific) importer/exporter, but for things like Customers and > > Vendors where there's not an src/engine/Account to match against, I'm > > not sure if the existing code will be trivially adaptable; those Vendors > > and Customers are different data-sources for matching purposes. Well there can be a match, it might not be by ID, but it might by some other field match. > > I doubt that any of the existing importer code will help with > any of the business objects. > > > Note that I'm speaking at a high-level, I'd be happy if you found the > > code was more sophisticated than I'm thinking. > > The existing code was pretty sophisticated in that you could plug > in various matching rules per object and such. But it was very buggy, > and it's been a long time since I've looked at it. Are you talking about the QSF code, or the other import/export code? > > David, you should ignore external QOF. It went off in a completely > different direction and at this point I don't think it would be trivial > to do a merge. And we're not at all interested in a merge because > frankly we've put a bunch of bug-fixes into the code and the last time > we had a merge those bug fixes were lost. Fine > > As for pulling up their QSF -- that COULD be an option, but I don't > think that the majority of work is in the QSF backend but rather in the > GUI frontend. If there is a viable alternative I am happy to go with it.
David > > There *is* QSF Import UI, but it's just not hooked into the Menus. > Take a look at ./src/gnome/gnc-plugin-basic-commands.c and in particular > the macro QSF_IMPORT_WORKS > > -derek _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
