Support für Banken ohne HBCI, sogenannter Scripting-Support

@Admin: Sollte dieser Thread nicht besser "sticky" sein?!

leider nun die Erkenntnis dass es uns nun leider nicht mehr möglich ist bestehende Beiträge wie meinen ersten Post nachträglich zu bearbeiten und somit pflegen zu können.
Aus diesem Grunde wird dieser hier nun nicht mehr aktualisiert oder erweitert.

Den Verweis zur aktuellen Zusammenstellung findet man aber dennoch oben
oder man besucht wie immer am besten http://hibiscus-scripting.derrichter.de (allein schon wegen den Updates)

somit schade aber was soll man da machen :bandit:

Nein. Das geht nicht.

Da muesste ja erstmal jemand eine solche gemeinsame API definieren. Diese API waere nicht unerheblich umfangreich. Anschliessend muessten alle existierenden Scripts dafuer umgebaut werden. Das waere ein riesen Aufwand. Anschliessend muesste sowohl Hibiscus als auch jede andere Software, die diese Scripts benutzen will, ebenfalls diese API implementieren.

Ich denke, da ist es weniger Aufwand, wenn du das gewuenschte Script einfach fuer deine Zwecke anpasst.

Die meisten Scripte stammen ja von Sebastian (http://hibiscus-scripting.derrichter.de/) - im ersten Schritt muesstest du also erstmal ihn ins Boot kriegen.

Also wenn Pecunia die Scripts ebenfalls nutzen koennte, waere das schon ein toller Mehrwert - das wuerde sicher auch Sebastians Motivation steigern.

Letztlich muessten wir eine Java-API definieren, ueber die das Script an die noetigen Konto-Informationen kommt, Callbacks ausfuehren kann (z.Bsp. fuer PIN-Abfragen) und die abgerufenen Umsaetze abliefern kann. Diese muesste dann sowohl von Hibiscus als auch von Pecunia implementiert werden. Aus meiner Sicht ist das aber ein nicht unerheblicher Aufwand.

Sorry für die späte Antwort. Ich wusste nicht, dass man e-mail Benachrichtigungen erst einschalten muss. Hoffentlich habe ich jetzt den richtigen Schalter umgelegt.



Mein Plan war, dich deswegen anzusprechen, wenn die ganze Sache bereit ist (was erst seit diesem WE der Fall ist).



Nun, dass waren tatsächlich nur eine handvoll Zeilen aus einem 4000 Zeilen Script und diese wurden auch noch angepasst. Deswegen sauer zu sein halte ich für übertrieben, aber vermutlich hätte man doch mal fragen sollen (eigentlich habe ich sogar angenommen man hätte dich gefragt). Allerdings ist es auch nicht so, dass es so viele Möglichkeiten gäbe die HTML Seiten und Element anzusprechen. Da wird es sich zwangsläufig nicht vermeiden lassen, dass unser Code deinem in den wesentlichen Dingen sehr ähnlich sieht. Jedenfalls hatte ich schon länger die Absicht, dich mit ins Boot zu holen damit wir nicht das Rad neuerfinden müssen.



Offen gesagt habe ich naiverweise angenommen, man könnte einfach angepasste Skripte für Pecunia aus denen von Hibiscus generieren, da ich mir das damals noch nicht näher angesehen hatte. Nach ein paar Wochen intensiver Beschäftigung damit habe ich jedoch erhebliche Zweifel, ob ein sharing überhaupt möglich ist. Nicht nur dass die Skript mittlerweile Unmengen an Hibiscus spezifischen Code enthalten, sie verwenden (natürlich) völlig andere Bibliotheken. In Pecunia benötige ich keinerlei extra Lib. Ich habe die volle Power von WebKit zur Hand und konnte damit sogar eine kleine Testumgebung für Skripte aufbauen, die es nicht erfordert die Anwendung laufen zu lassen. Außerdem läuft in WebKit alles asynchron. So eine einfache schrittweise und synchrone Abfolge, wie in den Hibiscusskripten verwendet, würden in Pecunia nicht funktionieren.




Ich lasse mich gern eines besseren belehren. JS ist nicht gerade meine Haus und Hof Sprache. Und es wäre geradezu hirnrissig all die enorme Arbeit, die in die Hibiscusskripte geflossen ist nicht auch für Pecunia zu verwenden. Aber im Moment sehe ich da erhebliche Probleme, ob der unterschiedlichen Technologien. Pecunia verwendet eine state machine, Hibiscus eine einfach synchrone Abfolge. Pecunia arbeitet mit WebKit, Hibiscus mit HTMLUnit. Ich bin für Ideen offen, würde aber extrem ungern eine zusätzliche Lib hinzuziehen wollen, wo ich doch alles in bester Manier zur Verfügung habe (vollen DOM support usw.). Außerdem benötigen wir vieles nicht, was in den Hibiscusskripten enthalten ist (z.B. Nutzer anlegen und anderer Verwaltungskram, den natürlich die App übernimmt).



Absolut. Allerdings müsste man wohl erstmal den App spezifischen Kram vom Kern trennen und APIs definieren, über die man dann diese Kern Funktionen aufruft. Außerdem wäre es gut auch das konkret genutzte Framework zu abstrahieren (app spezifische Wrapperklassen?), aber da müsste mal jemand einen Entwurf machen, der sich besser mit JS auskennt, als ich. Andererseits habe ich kein Problem damit meine Pecunia API aufzubohren, damit sie sauber mit der von den Scripten arbeitet. Da bin ich wiederum sehr flexibel, da wir noch am Anfang stehen.

Mike

achso da dass nicht klar rübergekommen ist ^^ ich rede hier natürlich nicht mehr von JavaScript sondern von einer Java-Bibliothek die ich somit zu verfügung stelle in der natürlich alles wichtige vom Hibiscus-Teil abgetrennt ist.

von Aufruf her ist dass dann ca so zu verstehen:


Dass ganze gibt dann natürlich auch z. B. .getPosteingangsnachrichten(....), usw. zurück und man erhält auch die Fehlermeldungen der Bank die ich ja alle parse ...

und diese kann auch fertige Matrix-Arrays mit den Umsätzen zurückgeben also statt String eine ArrayList usw. damit man den CSV-Kontoauszug nicht mal mehr selber parsen braucht. Dieser kann aber wie schon angedeutet je man Auswahl "String <gewünschter vordefinierter Aufbau aus einer Auswahl>" den "rohen CSV-Kontoauszug" der Homepage oder einen perfekt Vor-Formatierten Kontoauszug zurückgeben der immer den gleichen Aufbau hat.

Somit kann dass dann eben von jeder beliebigen Software genutzt werden ddie Java-Bibliotheken nutzen kann, was ja Pecunica macht soweit ich dass weis

Keine verstreuten Updates mehr, und keine so umfangreiche Variante einer gemeinsamen Schnittstelle mit gemeinsamer Syntax ...


eine genauere Beschreibung mit Doku gibts dann später


Gruß

dass verstehe ich jetzt zwar nicht ganz denn ich dachte Pecunica verwendet doch auch HBCI4Java??? also eben Java-Pakete? und dachte am Anfang hätte ich bei euch auch HTMLUnit gesehen (aber da hab ich mich wohl getäuscht)
Beim kurzen drüber schauen denke ich ist WebKit in der Entwicklung wohl nicht für Linux gedacht? was ja ein direktes Ausschlusskriterium wäre? und man hat auch noch verschiedene Entwicklungsumgebungen unter verschiedenen Systemen. Genau dass gefällt mir jetzt besser unter Java da egal auf welchem System ich arbeite ich immer die selben Voraussetzungen vorfinde. Zudem bräuchte man für die aktuelle JavaScript-Variante von Jameica gar keine Entwicklungsumgebung, man tippt einfach seinen Code in nen Texteditor und kann immer live testen ...

Aber gut dass hätte ich jetzt erst mal nur für euch so angefangen dann bringt dass natürlich nichts und ich kann meine Energie wieder anders konzentrieren wenn dass eh nicht verwendet wird ... Denn zwei verschiedene Scripte werde ich nicht pflegen da muss eben schon der gemeinsame Nenner her wie Olaf das auch richtig erkannt hat und ich dachte meine Lösung bringt auf einfachen Wege den gemeinsamen Nenner ohne dass man sich verrenken muss ... zudem funktioniert die auch ohne jegliche Bankingsoftware für jederman und über Java brauchen wir hier auch nicht zu diskutieren

Gruß

Ich verstehe nicht so richtig, wofür Webkit da verwendet werden soll. Als Alternative zu JUnit für den Zugriff auf die Webseiten aus dem Javascript heraus? Das wird nicht funktionieren. HTMLUnit ist ja letzlich nichts weiter als eine JAR-Datei, die direkt aus Javascript heraus verwendet werden kann, da der Scripting-Support von Java per ECMAScript den direkten Zugriff auf Java-Klassen und -Objekte zulässt. Eine Portierung auf Webkit ist in dem Sinne nicht möglich. Webkit selbst ist ja erstmal nur eine Rendering-Engine. Die gibt es natürlich auch unter Linux. Der Chrome-Browser verwendet die zum Beispiel. Und eigentlich ist WebKit ein Fork von KHTML, der HTML-Rendering-Engine des KDE-Browsers "Konqueror". Also eigentlich kommt WebKit sogar ursprünglich von Linux - nämlich vom KDE-Projekt.

Nun ist es aber so, dass gar nicht die Rendering-Engine selbst gebraucht wird sondern eine aus Javascript heraus benutzbare API, um einen Browser zu simulieren. Dazu braucht man die WebKit-Engine in Form einer Bibliothek und Zugriff per Javascript darauf. Weder das eine noch das andere ist mir bekannt - erst recht nicht für Windows, Linux, BSD, ... und das je in 32 und 64 Bit. HTMLUnit dagegen läuft auf jedem Betriebssystem, für das es Java gibt.



Das würde aber nur Sinn machen, wenn die einzige zu abstrahierende Seite die zur eigentlichen Anwendung zeigende ist (also Pecunia bzw. Hibiscus). Muss jedoch auch die Seite Richtung Bank (also der HTTP-Zugriff) abstrahiert werden (JUnit vs. WebKit), dann bleibt dazwischen quasi nichts mehr an Code übrig, was dann überhaupt noch gemeinsam genutzt werden könnte.