-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upstream/feature pdf import #185
Upstream/feature pdf import #185
Conversation
* Menu item to select files for importing * Wizard dialog to review extracted items Issue: portfolio-performance#45
…comdirect PDF files
Tut mir leid dass dieser branch so weit vornedran ist; den habe ich von master gebranched. Bei dem kleinsten Funken positiven Feedbacks baue ich das in das von @abuchen geschaffene Framework ein. |
Die ganzen extra Commits tauchen nur auf, weil Du auf den "feature_pdf_import" branch pushen möchtest, aber vom master gebrancht hast. Und der master ist mittlerweile etwas weiter, das ist aber auch nicht schlimm. Erstens bin ich überrascht wie wenig Zeilen Code es braucht... Hätte ich nicht gedacht. Ich kenne jetzt den Code von @tamueller noch nicht im Detail. Darum kann ich nicht gut beurteilen wo man noch Ähnliches refactorn könnte. Aber im Prinzip habe ich nichts dagegen, dass in den "Extractor" zu übernehmen. Mir ist aufgefallen, Du verwendest Java 7 Features. Momentan versuche ich noch zu Java 6 kompatibel zu bleiben, weil das auf verschiedenen Plattformen doch einfacher zur Verfügung steht (vor allem auf dem Mac). |
wenige Zeilen: Das Parsen ist wirklich nicht viel. Ich würde das Feature aber zuerst mal beta releasen, denn das parsen ist noch instabiler als HTML parsen. Es gibt einfach keine Tags. Im Moment arbeite ich mit Zeichenabständen in dem extrahierten Text. Bei meinen ~15 Beispiel PDFs funktioniert das. Keine Garantie dass das bei allen funktioniert. Man kann das bestimmt auch noch robuster machen (zB schauen ob danach Leerzeichen kommen). Java7: welche Features sind das? Dann kann ich die Java6 kompatibel machen Einbindung in Rahmen: Momentan hab ich keine Innere Klasse für das Resultat. Das passt logo nicht. Das hab ich nur gemacht weil ich das File in nem anderen Projekt entwickelt habe ... durch die Massen von Exceptions die ich in PP bekomme kann ich da nicht debuggen. |
Momentan bekommst Du im Extractor auch einen Anzahl von Dateien: In einem Verzeichnis gerade Strg-A oder per Shift einen Anzahl von Dateien auswählen halte ich für vertretbar. |
Ah ja. Das hatte ich so garnicht gesehen. Dann gut, dass ich das intuitiv genauso gemacht hab... |
…to upstream/feature_pdf_import separating Extractor interfact from the comdirect Implementation Conflicts: name.abuchen.portfolio/src/name/abuchen/portfolio/datatransfer/Extractor.java
Nach jeder Änderung an dem Application.e4xmi muss man einmal mit dem Flag |
Der Travis Build schlägt wegen OSGi Abhängigkeiten fehl. Wenn Du auf dem allerletzten Master commit aufsetzt, sollte es wieder tun. |
- Committing ComdirectPDFExtractor - Registering the Extractor in the Handler
So, also der Menueintrag ist jetzt da.
purchase.setShares(stueck.longValue() \* Values.Share.factor());
benutzt. in stueck steht die richtige Zahl mit Komma. Danach kommt da aber kein Komma bei raus, weil longValue eine Ganzzahl rauswirft. Muss ich hier das Resultata von stueck.doubleValue() \* Values.Share.factor() in ein long parsen?
|
zu 1)
Am besten noch runden: zu 2)
Ein fehlendes Wertpapier sollte man anlegen. In dem Beispiel habe ich das auch so gemacht:
In der Ergebnisliste sieht der Benutzer dann, dass ein neues Wertpapier angelegt wird.
Man könnte auch eine Spalte "Quelle" hinzufügen - da könnte dann der Dateiname stehen. Oder eben einen Log/Meldungsbereich. Im Prinzip habe ich da kein Problem mit wenn es den Dialog nicht unnötig kompliziert macht. Vielleicht "klappt" man den Meldungsbereich auch nur aus. Von mir aus kannst Du den Teil auch erst mal weglassen und in einem separaten Pull Request machen. Diesen ersten Change würde ich erst mal drin haben. Und dann die Merges kreuz und quer etwas aufräumen so dass wir eine schöne Historie haben. |
Der Build schlägt übrings fehlt wegen Java 7 Syntax:
Die musst Du noch separat catchen. Ich baue PP immer noch für Java 6. Zum Beispiel auf Mac OS X haben die meisten nur Java 6, wenn überhaupt. Und man muss bei neueren Versionen zwingend das JDK installieren, das JRE reicht nicht. Ich überlege schon, das JRE im Download mitzuliefern. Wenn der dadurch nur nicht so groß werden würde... dann könnte man freier die Java Version ändern. |
making parsing more robut by thinking in words not in string positions
mit 8bca4bd werden nun auch Gebühren aus Käufen geparsed, ich habe zwei Fehler beseitigt und das ganze ist deutlich robuster. |
Cool. Ich schaue mir das am WE an und merge das ggf. in den Branch. Ich hatte bei der Comdirect mal ein Tagesgeldkonto - die Auszüge müsste ich ja passen können. |
Tagesgeldkonto.... Das hat dann zwei schritte:
Der erste Schritt macht das ganze robuster, denn es gibt die gefahr von false positives, also dass man versucht einen kauf aus einem verkaufsdokument zu lesen |
name, wkn and isin is taken from the PDF
Fehlende Securities werden jetzt angelegt mit name, ISIN und WKN. getNextWord, getNextRow, getLastWordInCurrentRow usw... durchläuft. Ich hab ein wenig gesucht aber nichts entsprechendes gefunden. |
Ich bin jetzt dazu gekommen mir die Änderung mal anzuschauen. Leider habe ich selber keine PDF Auszüge von der comdirect. Und mein Konto habe ich vor einiger Zeit aufgelöst. Das bringt mich auch direkt zum ersten Punkt: Könntest Du einen Test hinzufügen? Vielleicht könnte man den Text eines PDFs extrahieren und das als "Testdaten" einchecken. Den Text kannst Du dann anonymisieren. Der zweite Punkt ist das Fehler Handling: Mir ist aufgefallen, dass es keine gute Möglichkeit gibt Fehlermeldungen an den Benutzer zurückzugeben. Ich schlage vor, die Methode Wenn Du ein Wertpapier anlegst (hier Und dann noch einige Kleinigkeiten:
Der nächste Extractor, der sowas braucht, sollte das dann extrahieren. Auf Verdacht hin sollte man da nix machen. Und mit den Tests sollte man das dann recht problemlos refactoren können. Der Pull Request ist mittlerweile schwer zu lesen. Wenn Du oben auf "Files Changed" wechselst, dann sieht man viele Änderungen die gar nicht von Dir gemacht wurden. Das liegt an den diversen Merges. Darum würde ich diesen Change relativ schnell abschliessen und einen neuen "drauf" setzen. |
adding created securities to the result
trying to pass errors during parsing either to the user or the general framework
Vielen Dank für Dein Feedback. Ich habe versucht alles zu machen. Test: Es ist für mich etwas schwer fest zu stellen, was ich da testen soll. Dass aus einer "Testdatei" die richtigen Transaktionen geparsed werden? Hast Du ein Beispiel an dem ich mich orientieren kann? Mit welchen Parametern wird so ein Test aufgerufen? Exceptions: Warum auch immer, bei mir kann er Java 7 Syntax. Das eine Beispiel habe ich angepasst. Das dumme ist ich erkenne keine Java 7 Syntax wenn ich sie sehe. Ich google einfach wenn ich was nicht weiß und dann ist der neueste Hit halt von der neusten Version. Wenn noch was da is nehm ich mich dem gerne an. Wir können diesen PR gerne zu machen und auf einen neuen von master aufmachen. |
Habe versucht einen Test hinzuzufügen. Leider hat es meinem Eclipse überhaupt nicht gefallen, das ich im Manifest des test Projektes die Dependency einbauen wollte (in dem Issue von @buchen geschrieben). Daher konnte ich den Test nicht laufen lassen. So könnte das aber aussehen. Die beiden Textdateien sind sicherlich nicht an der optimalen Stelle. So konnte ich sie ohne kompliziertes und absoluten Pfad ansprechen. Die Strings in die Klasse zu machen wäre wegen den Zeilenumbrüchen ein großer Schmerz gewesen. Zu guter Letzt habe ich noch den aktuellen Master gemerged damit der branch einfacher zu pullen ist. |
Vorsichtig! Schau Dir mal die Liste der "Files changed" von diesem Pull Request an. Da sind mittlerweile 94 Dateien aufgeführt. Klar muss man manchmal mergen (vor allem wenn der Build nicht tut)... das verstehe ich schon. Einfacher ist es, wenn man das Feature separat macht und den Merge beim "Merge pull request" macht!
Klar - PDFText und das Einlesen aus der Datei würde man nicht mehr testen. Aber das Parsen des Textes - und da liegt die meiste Logik, oder? Und die ist ggf. recht fragil weil sie auf reinen Text angewiesen ist. Der Test liegt doch an der richtigen Stelle. Ich würde noch
Die Dependencies hast Du aber hinbekommen, oder? Der Test scheint ja wegen etwas anderem fehlzuschlagen:
|
Die Tests sind bei mir nie gelaufen. Ich bekomme da classnotfound. Wenn ich das Manifest um das requirement von pdftext erweitere gibt er da nen fehler, dass der header mit ner newline beendete werden muss. Deshalb sind die Tests auch so generisch. Man könnte das noch genauer testen als das 2 Werte in der Liste zurückkommen. Der Test ist aber meines Erachtens eh sehr wackeling: Es stimmt vollkommen, dass die Logik nicht sehr robust ist. Aber sie ist ja gerade mit diesen Testdaten aufgebaut. Wenn dann kommt die Logik mit Dateien von anderen Personen ins Straucheln. Wenn sie schon diesen Test nicht schafft, dann ist eigentlich hopfen und Malz verloren. |
Dafür braucht es ja den Test. Wenn die nächsten Beispiele kommen und gefixt werden, muss man sicherstellen, dass die alten Tests weiterhin funktionieren. Außerdem habe ich bisher verstanden, dass Du PDF Dokumente von mehreren Jahren hast. Damit müsste doch der Code schon etwas generischer sein, oder?
Zentral scheint er zu laufen. Was machst Du lokal anders? Lässt Du das auch mit Maven laufen? |
Die Struktur der Dokumente ist halt konstant. Ich muss gestehen ich habe in eclipse Run=>JUnit Test gemacht. Wie starte ich den maven Test? |
Aus Eclipse heraus musst Du "JUnit Plug-in Tests" laufen lassen (siehe auch das readme.md im Projekt). Ansonsten von der Kommandozeile |
renaming test
So jetzt sollte (hoffentlich) alles tun. |
Travis sagt noch etwas anderes :-( Ich habe es gerade mal bei mir ausprobiert. Wenn Du den Whitespace Fehler im Manifest fixed und das new Temp() wegnimmst, dann läuft der Test bei mir auch in der IDE. Unten der Patch dazu. Wenn ich mir den Test anschaue, dann fallen mir noch ein paar Punkte auf:
Ansonsten bin ich die nächsten Tage geschäftlich unterwegs (devoXX in Antwerpen) und komme wohl eher nicht zu einem weiteren Review.
|
Squashed commits: [fcbfd61] removing Java v7 syntax [2cc9045] - Adding Menu Entry for Comdirect PDF parsing - Committing ComdirectPDFExtractor - Registering the Extractor in the Handler [fb91742] parsing Fee making parsing more robut by thinking in words not in string positions [a64ee53] creating Securities if they are not present in the client name, wkn and isin is taken from the PDF [f820c73] added property for comdirect PDF import [87470cc] adding parameter List<Exception> errors to Extractor interface [7ea1f2c] memorizing newly created securities for future parsing adding created securities to the result [dccaa89] removing java 7 syntax trying to pass errors during parsing either to the user or the general framework [fefce0e] refactoring the extract logic to enable a test to pass a string [ad17c8c] trying to add a Test [aee2a16] moving test data to testcase renaming test [dfa10f1] fixing manifest (enhancing tested parameters) [ae1314b] adding missed value factor for Gutschrift total [187cc44] changing transaction type of Gutschrift from Interest to Dividend Pull-Request: #185 Signed-off-by: simpsus <bastian.kennel@gmail.com> [squashed commits into one; based on top of branch] Signed-off-by: Andreas Buchen <andreas.buchen@gmail.com>
Hi @simpsus, ich habe den Pull Request jetzt gemergt. Und zwar in den Branch "feature_pdf_import". Um den mit dem Feature / Branch einfacher zu arbeiten, habe ich jetzt folgendes gemacht:
Auf dieser Change mache ich dann noch ein paar kleine Änderungen zum Exception Handling. Und dann mache ich ein neues Ticket auf für Änderungen die notwendig sind, damit wir das überhaupt "ausliefern" können (Fehler anzeigen, etc.). Diesen Pull Request können wir dann schliessen. Alle neuen Änderungen am einfachsten in einem Branch auf dem neuen Commit. Wenn die entsprechend klein sind, dann kann ich die auch direkt über das UI hier mergen. Bei diesem Pull Request war mir das zu groß und unübersichtlich geworden. Nur damit das einigermassen Sinn macht, hier der Screenshot vor dem interactive rebase :-) |
No description provided.