Moin, wer das SVN-Repository von AqBanking und Co verfolgt, wird festgestellt haben, dass sich momentan in AqBanking und Gwenhywfar einiges tut :-)
AqBanking wurde von mir zu Beginn entwickelt unter der Annahme, ich wuerde spaeter Anwendungen darauf basieren (so wie QBankManager). Es hat sich aber herausgestellt - auch durch eines meiner neuen Projekte - dass AqBanking bisher mehr dazu verwendet wird, bereits bestehende Anwendungen (GnuCash, KMyMoney) zu erweitern. Da ich so etwas schon geahnt hatte, gab es ja bisher in AqBanking eine vereinfachte API fuer Programme, die sich mit den Interna von AqBanking nicht auseinandersetzen wollen, bzw. um die Einbindung von AqBanking in bestehende Programme zu erleichtern. Ausserdem "krankte" AqBanking ein wenig daran, dass es zwar wohldefinierte Callbacks fuer die Benutzer-Interaktion gibt (die verschiedenen Callbacks in AqBanking), diese aber beispielsweise von den Gwen-Plugins (fuer DBIO oder CryptToken) nicht zur Verfuegung stehen (weil dann ja Gwen wiederum von AqBanking abhaengen muesste). Das hatte ich damit umgangen, dass ich in Gwen ebenfalls ein paar User-Interaction-Mechanismen eingebaut hatte (GWEN_WaitCallback, GWEN_CryptManager). Das ganze ist inzwischen so kompliziert und verflechtet, dass nicht einmal ich selbst ohne nachzulesen genau weiss, an welcher Stelle ich welche Abfragen abfangen muss. Das ganze wird nun radikal anders. Da ich in Gwen ja auch jetzt schon User-Interaction habe und benoetige, habe ich nun in GWEN ein Modul erstellt, dass wie vorher AqBanking diese Interaction abfaengt. Das geschieht mittels des neuen Moduls GWEN_GUI. Standardmaessig ist ueberhaupt keine GUI gesetzt, somit werden entsprechende Anfragen also ignoriert. Eine Anwendnung - und zwar nur diese - kann und soll ein eigenes GWEN_GUI-Objekt zur Verfuegung stellen, dass die User-Interaction uebernimmt. Beispielsweise gibt es inzwischen innerhalb von AqBanking zwei solche Implementierungen: Eine fuer die Konsole und eine fuer QT. Damit entfaellt die Notwendigkeit, in AqBanking solche Callbacks zu verwalten, und tatsaechlich habe ich GWEN und AqBanking inzischen schon so weit umgestellt, dass es fuer eine Anwendung nur eine einzige Klasse gibt, die implementiert werden muss, damit saemtliche User-Interaction abgefangen werden kann. Da diese Aenderungen sowohl an Gwen als auch an AqBanking die API veraendern, habe ich gleich die Gelegenheit genutzt, beide Projekte ein wenig aufzuraeumen und zu entruempeln. Damit bin ich in GWEN auch schon so ziemlich fertig, jetzt bin ich gerade dabei, AqBanking anzupassen. Die meisten Plugins lassen sich auch schon wieder kompilieren. Bei AqBanking gibt es noch weitere Aenderungen: Inzwischen verwaltet AqBanking selber keine Joblisten mehr. Zum einen hat kaum eine Anwendung jemals das Queue-Management verwendet - unser "Hauptkunde" Gnucash zum Beispiel verwendet das ueberhaupt nicht, und QBankManager benutzt nur am Rande die EnqueuedJobs - zum anderen entstand dadurch eine ganze Menge Ballast in AqBanking. Ausserdem ist die Verwaltung von Auftraegen ohnehin eine Aufgabe der Anwendung. Als naechstes werde ich noch den Online-Banking-Teil weiter separieren: Bisher gibt es ja nur eine globale AB_Banking_Init-Funktion. Diese Funktion liest bisher saemtlich Informationen aus den Konfigurationsdateien ein, insbesondere die fuer Online-Banking. Damit kann aber - solange AqBanking initialisiert ist - keine Anwendung auf diese Daten zugreifen, weil sonst beide Anwendungen gegenseitig die Daten ueberschreiben wuerden. Bisher ist aber AB_Banking_Init auch dann noetig, wenn man nur die Informationen zu Laendern, Waehrungen, Banken etc verwenden will. Das soll nun anders werden. Zukuenftig wird es eine globale AB_Banking_Init()-Funktion geben, die aber wirklich nur das noetigste initialisiert (Pfade fuer Plugins etc). Wenn man dann die Online-Banking-Funktionen verwenden will, muss man eine zusaetzliche Funktion aufrufen (den Namen habe ich mir noch nicht ueberlegt, aber sinngemaess so etwas wie AB_Banking_OnlineInit. Andere Vorschlaege sind willkommen). Des weiteren kuemmert sich AqBanking zukuenftig nicht mehr um die Vor-Pruefung und das Cachen von Pins. Das ist ebenfalls etwas, das besser eine Anwendung tun sollte (und ueber die GWEN_GUI-Klasse auch kann). Insgesamt soll AqBanking damit schlanker und vor allem einfacher werden, frei von Funktionen, die lieber eine Anwendung uebernehmen soll. Ausserdem verspreche ich mir insbesondere von der Vereinfachung des Abfangens von Benutzerinteraktion eine bessere Wartbarkeit und leichtere Verwendbarkeit durch Anwendungen, da man nun nicht mehr an so vielen Stellen nachschauen muss :-) Gruss Martin -- "Things are only impossible until they're not" AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Aqbanking-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
