Moin, da bin ich wieder!
Habe das ganze mal etwas vereinfacht und zugleich flexibilisiert: https://youtu.be/WCukm_z8o7w
(Diesmal mit “richtiger” Tonspur, für Leute, die lieber meine Stimme hören als Disco Lounge Mukke.)
Du, @maxlrain, hast Dich ja schon positiv geäußert – jetzt braucht es nur noch grünes Licht von Großmeister @AndreasB.
PS: Es ginge auch %{PAGE}, sequenziert von 1 bis… es nichts neues mehr gibt.
Die Idee ist wirklich cool, ich würde es sogar direkt als Pull Andreas vorschlagen. Dann könnte er auch gleich die Auswirkungen auf den Sourcecode sehen und Tipps geben.
Ein/zwei Frage hätte ich da noch. Wiederholt dieses Feature eigentlich dann bei jedem Programmstart die vollständige Schleife über die letzten Jahre oder werden nach dem ersten vollem Download nur noch Lücken aufgefüllt? Wie verhält es sich wenn bereits Kurse vorhanden sind, werden diese dann überschrieben? Und, lässt sich der Zeitraum eingrenzen?
Schöne Grüße
Marco
Klar - push mal einen PR auf Github, dann können wir schauen wie wir das einbauen. Ich habe auch schon mal überlegt, ob man Platzhalter eingeben kann. Die Platzhalter oben habe ich noch nicht ganz verstanden - es sieht mir so aus als würden mehrere Abfragen gemacht?
Auf jeden Fall habe ich beim Kurs-Download auch das Datum des letzten historischen Kurses. Je nachdem könnte man die URL auch anpassen. Zum Beispiel sowas wie {lastHistoricalDate-1d;yyyy-MM-dd} könnte das in dem angegeben Format einfügen.
Moin an alle die hier noch mitlesen!
Danke noch einmal für das positive Feedback bezogen auf den Grundsatz / die Idee.
Mittlerweile habe ich Seite an Seite mit Großmeister Andreas getüftelt… und er hat ein Machtwort gesprochen:
Ich nehme die Change mit rein. Vermutlich nächstes Wochenende werde ich eine neue Version bauen und veröffentlichen.
Nun heißt es nicht mehr %{DATE:yyyy-MM-32} oder %{PAGE}, sondern {DATE:yyyy-MM-32} oder {PAGE}.
Nachdem ich diesen Post hier fertig habe, mache ich mich an die Tests und dann… heißt es eigentlich nur noch abwarten. 
Und eine Sache vielleicht noch: Wenn ihr euch und anderen hier einen Gefallen tun wollt, nehmnt doch bitte bspw. bei so krummen Monatsangaben wie bei Ariva, JJJJ-MM-{letzter Tag} aus Prinzip yyyy-MM-32 und nicht etwa 31. Aus eigener Erfahrung u.a. als Berufsprogrammierer kann ich dieses “Ausreiz-Prinzip” vielerseits empfehlen: Entweder es fährt alles “gegen die Wand” (den 32. Monatstag gibts so nicht) oder alles funktioniert – aber bitteschön kein inkonsistenter Zustand dazwischen!
Genug geschrieben, jetzt heißt es: weiter tüfteln.
Ich bin raus, euer Klaus.
Mit Version 0.32.0 sind die dynamischen Macros jetzt drin.
Und es gibt auch ein bisschen Dokumentation.
Hört sich gut an. Funktioniert das auch mit onvista?
als Vorlage, daraus wird
??? Der zweite Link ist natürlich so nicht aufrufbar, in PP geht es aber auch nicht.
Was habe ich noch nicht verstanden?
Hallo @ProgFriese und Danke fürs Testen!
Das (und die Berichterstattung hier natürlich) sind in der Softwareentwicklung unerlässlich.
Ich habe es bei mir getestet und mir ist folgendes aufgefallen:
MfG, AK
Faszinierend!
Mit https://www.onvista.de/onvista/times+sales/popup/historische-kurse/?notationId=3193857&dateStart={DATE:31.12.yyyy}&interval=Y1&assetName=MSCI%20WORLD%20&exchange=außerbörslich bekommt man beim Editieren des Links Daten zurück bis 1970, obwohl es bei onvista ja ein Startdatum ist. In den daraus resultierenden historischen Kursdaten sind diese 1970er-Werte nicht vorhanden.
Verstanden habe ich es noch nicht - aber es wirkt 
Das war ich nicht. Foren-URL-Encoding oder so etwas, egal.
Wo auf der Seite hast du denn diesen Link gefunden? Was kann man hinter exchange= angeben?
Ganz toll wären weitere Macros für {WKN} oder {ISIN}, und auch wenn man in der dynamischen URL bei onvista nach ISIN suchen kann. Dann brauchte PP am Ende nur noch eine globale Default URL.
Ich finde auf onvista.de unten bei Historische Kurse nur die Links “CSV runterladen” und “Druckansicht”.
CSV-URLs wäre als Import für PP auch nicht schlecht, anstelle von HTML parsen wäre das wohl auch stabiler.
Die Druckansicht wird aber auch erfolgreich gelesen von PP, die URL ist seltsam lang, geht aber::
https://www.onvista.de/derivative/snapshotHistoryPrint?idNotation=148153411&datetimeTzStartRange=01.12.2017&datetimeTzLastRange=06.07.2018&exchange=Emittent%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Emittent%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Emittent&codeResolution=1D
Wie würde ich hier mit dem {DATE} Macro arbeiten? StartRange kann ich ja fix auf 01.01.2010 setzen, das LastRange müsste aber dynamisch das heutige Datum sein. 2 Macros in der URL sind ja laut Dokumentation nicht möglich.
Ich habe die Doku nicht gelesen und schon gar nicht geschrieben – obwohl ich diese Funktion initiiert und entwickelt habe. Umso genauer kann ich darüber Auskunft geben, wie das ganze (tatsächlich) funktioniert:
Du kannst soviele Makros angeben wie Dein Arbeitsspeicher reicht (ich bin mal schnell bei Amazon… ), aber Du darfst nicht verschiedene Arten von Makros mischen. D.h. https://192.0.2.1/?start={DATE:01.01.yyyy}&end={DATE:31.12.yyyy} geht (und sollte auf Deinen Fall übertragbar sein), aber bei https://192.0.2.1/?start={DATE:01.01.yyyy}&end={DATE:31.12.yyyy}&p={PAGE} ist Schluss mit lustig.
Hintergrund:
Bloß nicht! Damit belastest Du den Anbieter unverhältnismäßig ohne dass es Dir etwas bringt. Meine persönichte Empfelhung:
https://192.0.2.1/?start={DATE:01.MM.yyyy}&end={DATE:32.MM.yyyy}https://192.0.2.1/?start={DATE:01.01.yyyy}&end={DATE:31.12.yyyy}Hmm… Je mehr ich darüber nachdenke, desto besser gefällt mir die Idee… ich habe es mir mal auf die ToDo-Liste gesetzt. Aber bevor ich das einbaue, wüsste ich gerne (von Leuten, die sich mit einigen representativen Kurslieferanten rumschlagen), ob diese Art der URL-Variation so verbreitet und auch wirklich so einfach ist – und diese Funktion damit verhältnismäßig ist. Gegenbeispiel: boerse.de
OK… habe nichts gesagt: Diese künstlich aufgeblähten URLs…
https://www.boerse.de/historische-kurse/Discount-Zertifikat-auf-Daimler-BNP-Paribas-Emissions-und-Handelsges-/DE000PP748L6
… lassen sich auch willkürlich abkürzen:
https://www.boerse.de/historische-kurse/DZ/DE000PP748L6
Das gleiche bei OnVista.
Das ist dann wohl falsch. Man kann mehrere Marcos in der URL verwenden - aber immer nur von einem Typ. Wobei ich mir den aktuellen PR noch nicht im Detail angeschaut habe: vielleicht ändert sich das mit den weiteren Marcos.
Oben rechts gibt es 
Edit Link. Die Dokumentation ist einfach ein anderes GitHub Projekt.
Neuerdings kannst Du die Typen auch durchmischen, wichtig ist nur, dass Du nicht mehr als einen “uneingeschränkt variablen” Typ hast (DATE + PAGE, die mit Macro#getVariableURLConstructor() != null). Das Problem ist, dass diese fortlaufend iterieren und Du (AFAIK) mehrere unbeschränkte Iterationen nicht sinnvoll zusammenlegen kannst.
Yahoo findet bei manchen Werten einfach nichts auch wenn es ein Kürzel gibt, wie bei diesem:
AT0000746748
IWTQ.F
676337
Daher überlege ich bereits, alle Werte von ariva zu nehmen.
Soweit ich das nun verstanden habe, wäre die passende URL:
https___www.ariva.de/espa_stock_biotec_a_%28eur%29-fonds/historische_kurse?boerse_id=8&month={DATE:yyyy-MM-32}
(Das Forum hat mir nicht erlaubt, den Link zu posten, daher musste ich ihn etwas abwandeln…)
Über boerse_id kann man bequem den Handelsplatz wählen.
Warum war nun das Format yyy-MM-32 ideal? Warum nicht 31 und warum überhaupt nicht -dd?
Wenn die Dokumentation nun in diesem Punkt noch aktuell ist, wird er beim ersten Mal rückwärts alle Kurse abrufen, bis keine mehr kommen. Das ist teuer für den Anbieter. Beim nächsten Mal würde er nur noch vom letzten vorhandenen Kurs aufwärts bis zum aktuellen Datum abrufen, also nur noch die fehlenden?
Kann man die URL der /historischen_kurse bei ariva nun auch beim Tab “Aktueller Kurs” verwenden, oder wird hier immer der aktuelle Kurs fehlen?
Hallo @Mssm und danke für Deine kritischen Fragen! (Heutzutage ist sowas Mangelware…)
Die Empfehlungen bzgl. des 32. und konstanten Monatstags in der Doku (die ich mittlerweile gelesen habe) hat Andreas von mir übernommen. Ich selbst habe sie aus folgendem Grund abgegeben:
Den klassischen Nutzer interessieren weder die Programm-Abläufe, noch die Konsequenzen, sondern nur, dass es geht – einmal eine URL zusammenbauen und fertig! Deshalb habe ich mir diese Empfehlungen überlegt, aus denen eine URL hervorgeht, die alles abdeckt:
In den ersten 2 Fällen wäre eine tagesbasierte URL eine 30x größere Last für den Anbieter und 30x längere Wartezeit für den Nutzer als eine monatsbasierte. Im letzten Fall macht es nicht sonderlich viel aus, da manche auch mal gerne wöchentlich aktualisieren. Und selbst wenn nicht, macht es wenig aus, ob Du Dir nur den Kurs von gestern oder für 31 Tage holst. Die 31-Tage-Abfrage ist bei den Anbietern Standard. Wenn man das Intervall bspw. auf ein Jahr anhebt (sofern überhaupt vom Anbieter unterstützt), nützt das zwar in den Fällen 1 und 2, aber schadet im 3…
Und den Hintergrund zum 32. Monatstag… hat Andreas bereits hinreichend in der Doku zitiert.
Aktuelle Kurse: keine Ahnung, habe mich nie mit denen beschäftigt.
MfG, AK