@Nirus, wär es denk- und umsetzbar zu jedem einzelnen Importer im Code den Link zu dem jeweiligen Thema hier im Forum zu hinterlegen und bei Fehlermeldungen anzuzeigen (ggfs sogar anklickbar)?
Geht gerade am eigentlichen Thema hier vorbei. Gerne diesen Post löschen, wenn du ihn gelesen hast, @Nirus.
Hallo @OnkelDok
also wenn ich einen PDF-Debug aus dem Forum als PR setze, dann füge ich immer im Kommentar den Link aus dem Forum bei. Zusätzlich noch den Link in den Importer schreiben, macht für mich keinen Sinn oder verstehe ich deine Frage falsch?!
Gruß
Alex
Ich meinte, dass der Link in der Programmoberfläche für die Benutzer*innen angezeigt wird, sobald der entsprechende Importer eine Fehlermeldung zeigt. Ggfs mit kurzer Erläuterung in der Form “Bei Importproblemen bitte im Forum informieren/lesen/melden/nachfragen: [LINK]”.
Damit man nicht im Forum suchen muss oder fälschlicherweise ein neues Thema aufgemacht wird, sondern genau an die richtige Stelle geleitet wird.
Das dürfte nicht möglich sein, nicht in der jetzigenForm wie der Import arbeitet. Bis vor einigen Jahren musste der User noch auswählen, welche Schnittstelle verwendet wird. Es wurde dann so geändert, dass jeder Importer versucht das PDF zu lesen. Im Fall des Falles werfen alle einen Fehler, welcher Link soll dann angezeigt werden?
Es gibt Vorteile und Nachteile, derzeit können verschiedene Banken gleichzeitig bearbeitet werden.
Ah ok. Das war mir nicht bekannt. Dann geht das natürlich nicht. Ich hab vermutet, dass zunächst aus eindeutigen Kriterien automatisch der jeweilige Importer gewählt wird, welcher dann den Importvorgang versucht.
Danke.
Für Techniker:
Die Vergangenheit, bis 2019:
Es gibt nur noch Variante mit der “Suche über den Bank Identifiers”…
Hallo,
beim Aktualisieren eines PDF-Importers ist mir wieder aufgefallen, dass Eclipse aus irgendeinem Grund die komische Angewohnheit hat, den Source extrem komisch zu formatieren.
Beispiel:
Hallo @auchri
im Menü → Quelltext → Bereinigen kann ich dir schon mal ans Herz legen.
Hier meine Konfigurationen für PP
Konfiguration Bereinigung - PDF-Importer.xml (10,2 KB)
Diese kannst du auch importieren.
Und nebenbei “STRG+Shift+F”
Gruß
Alex
@auchri
Ansonsten lassen wir alles(!!!) auf Standard in Eclipse… das vereinheitlicht den Sourcecode für alle(!!!) contributer.
Gruß
Alex
Danke, ansonsten ist alles auf Standard 
Bei STRG+Shift+ F kommt genau der Code aus dem Screenshot raus. Aber dann solls so sein 
Normalerweise ja, aber in einer Characterclass nicht. (zumindest bei PCRE, keine Ahnung was PP nutzt)
Darum ging es wohl.
Danke!
Jein.
1\.2 matched nur “1.2”).1[.]2 matched auch nur “1.2”, genau wie 1[\.]2). Siehe regex101.com:(Vgl. auch Java RegEx meta character (.) and ordinary dot? - Stack Overflow und die folgende Antwort)
Ähnliches gilt übrigens für [\w]{3}: \w ist schon eine Zeichenklasse (nämlich alle “Wortzeichen”), man braucht das nicht noch einmal in eine Zeichenklasse zu packen. Anders gesagt: \w{3} ist genau dasselbe wie [\w]{3}.
Die REs sind selbstverständlich nicht falsch, nur etwas ausführlicher als nötig. Darauf wollte ich hinweisen (denn REs sind ja ohnehin schon nicht lesefreundlich, deshalb mE lieber so kurz wie möglich schreiben).
Ja, ich weiß. RE waren praktisch meine Muttermilch.
Schaden tut es aber auch nicht Sourcecodeoptimierung (da zähle ich den RE jetzt einfach mal dazu) ist nicht so mein Ding, genauso wie ich bei Operationen gerne zu viele als zu wenige Klammern setze. Von daher sollte IMHO der Backslash bleiben, u.a. um anderen Sourcecodeafficionados, die nicht RE-sattelfest sind - zu zeigen, dass man hier wirklich einen Punkt meint und nicht “beliebiges Zeichen”.
Bei Sourcecode können Klammern die Lesbarkeit verbessern. Dass Backslashes in Regulären Ausdrücken die Lesbarkeit verbessern, bezweifle ich. Zumal es ja im Java-Code immer zwei sein müssen – also hier [\\.] statt [.].
Und was spricht für [\\w] statt \\w? So was findet sich häufig im Code, z.B. hier
Nr\\.[\\s]{1,}[\\d+]\\/(?<year>[\\d]{4}) (new PDF Importer for J&T Direktbank by ZfT2 · Pull Request #3748 · portfolio-performance/portfolio · GitHub). Das ließe sich äquivalent schreiben als
Nr\\.\\s+\\d+\\/(?<year>\\d{4})
Ein anderes Beispiel dafür:
[\\d]{2}\\.[\\d]{2}\\.[\\d]{4} (aus Modify ING Diba PDF-Importer to support new transaction by Nirus2000 · Pull Request #3749 · portfolio-performance/portfolio · GitHub)
Das ist dasselbe wie
\\d{2}\\.\\d{2}\\.\\d{4}
nur länger und schwieriger zu erfassen.
Ich sehe nicht, dass die überflüssigen eckigen Klammern etwas für die Lesbarkeit tun (und auch nicht, warum man im ersten Fall inkonsistent {1,} statt + schreibt).
Aber ich muss den Code ja auch nicht ständig lesen. Also nicht meine Baustelle, sondern nur meine Vorschläge.
Das kann ich gut verstehen. Man sollte aber gerade bei RE genau das schreiben, was man meint und will. Nicht mehr (und erst recht nicht weniger )
In erster Linie, um die Lesbarkeit zu verbessern (dazu gibt es ja offenbar unterschiedliche Auffassungen). Aber auch, um blöde Bugs zu vermeiden, etwa die Backtracking-Katastrophe, die seinerzeit Cloudflare böse ausbremste.
Hallo,
Im Master Ich habe zwei JUNIT-Fehler, bei testLimitPriceConverter_deCH
und testLimitPriceConverter_deDE in portfolio.model.AttributeTypeTest, aber ich denke, das sind Fehlalarme. Dennoch kann es bedeuten, dass etwas im Test korrigiert werden sollte, aber ich bin mir nicht sicher, was. Ich denke, der Expected ist falsch.
Zweiter Punkt: Wenn ich aus Eclipse starte, öffnet sich PP mit der Spracheinstellung Automatisch. Wenn ich sie ändere, speichere, schließe und wieder öffne, ist Automatisch wieder eingestellt. Das bedeutet, dass PP von Eclipse aus nur auf Französisch geöffnet werden kann, was ein wenig unpraktisch ist, wenn ich einen Screenshot der Korrektur/des kleinen Features zeigen möchte.
Sorry, wenn dies nicht der richtige Thread ist, ich dachte nicht, dass es ein Github Issue wert war.
Übersetzt mit DeepL.com (kostenlose Version)
Ich vermute das liegt auch an der Lokalisierung. Der Test prüft die lokalisierte Fehlermeldung. Das Problem scheint daran zu liegen, dass ein Text mit Apostrophe durch das MessageFormat geschickt wird - das verändert den Text. Das habe ich behoben. Just FYI für @kimmerin
Während der Entwicklung, kannst Du die Sprache über den Parameter -nl einstellen. (Ich meine die werden von Eclipse ansonsten mit den Parametern Deines Eclipse Workspace vorbelegt).
Hallo Andreas,
Danke, beide Themen sind behoben!
Was die Sprache angeht, war ich überrascht, weil ich denke, dass sich dieses “automatische” Verhalten erst kürzlich geändert hat. Ich war in der Lage, die Sprache von einem Eclipsed-gestarteten PP vorher zu wechseln.
Die Message in der Exception prüfe ich, um sicherzugehen, dass im Test auch wirklich die Exception geworfen wird, die ich an der Stelle erwarte (hatte ich schon mal, dass der Test einen Daumen nach oben zeigte, obwohl eigentlich was schiefgegangen ist, beide Fälle aber die gleiche Art Exception erzeugten).
Da die Exceptionmessages schon fertig lokalisiert geworfen werden, muss man gegen diese testen. Mir ist es nicht gelungen - sei es durch @Before oder @BeforeClass ein fixes Locale zu setzen, das dann beim Laden der Sprachdateien berücksichtigt wird; immer war das schon an der Stelle durch und in meinem Fall die deutschen Meldungen schon geladen.
Wo wäre das? Ich habe da Zweifel, da ich ehrlich gesagt nicht wüsste, wo man ein Default-Locale im Workspace einstellen könnte (Encoding schon). Für mich sieht das so aus, als ob die Spracheinstellungen des OS an die Applikation weitergereicht werden, da PP bei mir aus Eclipse heraus mit deutschem Locale hochfährt (und wie oben beschrieben die Unittests auch deutschsprachig sind), während Eclipse selbst hier mit englischer Lokalisierung läuft.
Da hast Du vermutlich recht. Es wird einfach die Locale von dem Eclipse IDE Prozess and die Tests weitergegeben.
