Sounds cool. This is probably a big step forward to enable more uniform importer (or other) druids.
That was my intention. It should also make it a lot easier to add new importers as MOST of the GUI work should be done... For example, once I get the QIF stuff done, a CSV importer has almost all its UI requirements complete. The only exception of the CSV importer is the column matcher.
As for my HBCI code, I would've been happy to use it when I hacked the druid(s) together, but given that the HBCI code is now up and running, I will probably not touch that code again too much :-)))
Well, we might touch it for you in the name of consistency.. ;
AAAAARGGGG!
Is there a "test HBCI server" we could use if we go that route? Seriously, I'd like to get a coherent interface (that makes sence) for ALL the importers.
There are at least two test servers around (http://hbci-kernel.de and http://hbci4java.kapott.org/demoserver.html). Nevertheless, because every real bank has a different HBCI implementation which may or may not be different from the actual standard, I recommend against changing the HBCI code in nontrivial ways if you don't actually *use* this code with *real banks*. Really.
Also, the HBCI code is not "one importer": It consists of one Setup druid, which is being used several times during setup, and then of three distinct "actions" which sometimes don't have any UI widget at all. Maybe some parts of that can be improved by being changed into this new framework. But I want to state up front that the very nature of the HBCI code is quite different from being "one importer".
Let me know what you think about this design..
From what I can see it definitely looks good.
Thanks. Glad it makes sense to you.
Welcome.
Christian
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
