From 011724dbc6e6c0b3babeb86c075f74477d885585 Mon Sep 17 00:00:00 2001 From: Kai Moritz Date: Sun, 19 Oct 2025 13:56:38 +0200 Subject: [PATCH] TODO --- TODO.patch | 17 ++++++ TODO.txt | 131 ++++++++++++++++++++++++++++++++++++++++++++++ projects/TODO.txt | 6 +++ 3 files changed, 154 insertions(+) create mode 100644 TODO.patch create mode 100644 TODO.txt create mode 100644 projects/TODO.txt diff --git a/TODO.patch b/TODO.patch new file mode 100644 index 00000000..13dfef7b --- /dev/null +++ b/TODO.patch @@ -0,0 +1,17 @@ +diff --git a/dist/http-resources/2.0.0/index.html b/dist/http-resources/2.0.0/index.html +index e430a2d..951be4b 100644 +--- a/dist/http-resources/2.0.0/index.html ++++ b/dist/http-resources/2.0.0/index.html +@@ -218,9 +218,11 @@ + xmlns="http://www.w3.org/1999/xhtml" + th:replace="~{/templates/layout.html :: layout( + uri='/http-resources/2.0.0/index.html', ++ title=~{:: title}, ++ maincontent=~{:: .maincontent}, + json='MERGE: + { +- "_names": { ++ "_titles": { + + "/http-resources/2.0.0/dependencies.html": "Dependencies" + , diff --git a/TODO.txt b/TODO.txt new file mode 100644 index 00000000..07eb199a --- /dev/null +++ b/TODO.txt @@ -0,0 +1,131 @@ +Die Reihenfolge ergibt sich aus der zeitlichen Entwicklung: +Neue Themen werden oben ergänzt - altes nach unten verdrängt + +* Es erscheint vorteilhaft, wenn man in der Konfiguration (Klasse Site) + die Patterns und Exclusions zusammen mit der betreffenden Remote-Site + vorgibt. + * Diese Änderung müsste auf Ebene von http-proxy umgesetzt werden + * Dafür müssten dort die Resource-Chain und der Resource-Loader beide + die Konfiguration kennen und nur dann auf eine Remote-Site zugreifen, + wenn ein Pattern matched, aber keines der Exclusions + * BEACHTE: Die Resource-Chain würde ab dann nur noch wie erwartet + funktionieren, wenn der HttpResourceResolver eingesetzt wird, da diese + ansonsten über den (in Version 2.0.0 zwingend erforderlichen) + HttpResourceProtocolResolver ohne Beachtung der Exclusions auf die + Remote-Site zugreifen würde + * Man könnte zwar erreichen, dass die Resource-Chain auch ohne den + HttpResourceResolver, nur mit dem HttpResourceProtocolResolver + wie erwartet funktioniert, wenn man den ProtocolResolver so abändert, + dass auch er die zu den Remote-Sites gehörenden Exclusions beachtet. + Dann würde dieser aber im Standalone-Betrieb ggf. nicht mehr + funktionieren, wie erwartet, da er hier der Erwartung nach als + Drop-In-Replacement verwendet wird, um das Caching der Default- + Implementierung zu verbessern + * D.h., hier schält sich auch langsam eine eindeutige Trennlinie + zwischen den Anwendungsfällen heraus, für die der ProtocolResolver + gedacht ist, und denen, für die die Resource-Chain gedacht ist - in + der Implementierung 2.0.0 ist dies noch vermischt, da der + ProtocolResolver für den Betrieb der Chain benötigt wird, der + HttpResourceResolver aber nicht (!!) + * BEACHTE: Derzeit setzt Thymeroot die Exclusions dafür ein, + /templates/** unverändert sichtbar zu machen - also ohne, dass diese + von Thymeleaf interpretiert werden, was bei den Templates nur zu + Fehlern führen würde + DIES WÜRDE NACH OBIGER ÄNDERUNG NICHT MEHR FUNKTIONIEREN + * Es müsste also ein neuer remote-site-übergreifender Parameter + eingeführt werden, um dies weiterhin zu ermöglichen + * Dieser würde wohl am sinnvollsten in HttpResourcesTemplateResolver + zu konfigurieren sein + * Damit Thymeroot die über diesen Parametre ausgeschlossenen + Templates dann auch ignoriert, damit sie als statisches Asset über + die Resource-Chain aufgelöst werden, müsste der ThymerootController + die konfigurierte Instanz von HttpResourcesTemplateResolver kennen + und über diese Prüfen, ob die angefragte URL zu einer verfügbaren + View gehört - Ähnlich wie dies zwischenzeitlich schon mal umgesetzt + war, bevor die Auflösungs-Reihenfolge vom + HttpResourcesTemplateResolver in den + HttpResourceChainAwareResourceLoader verlegt wurde +* Die Resource-Chain so umkonfigurieren (umkonfigurierbar machen), + dass gar keine lokalen Resourcen mehr existieren. + Lokale Resourcen (und das Überschreib-/Fallback-Beispiel) machen + auf der Stufe von ThymeProxy Sinn - Hier geht es ja um eine + leere Hülle (die ThymeRoot), die _alle_ Inhalte Remote (aber + konfigurierbar staffelbar!) einsammelt! + * Ggf. könnte es noch Sinn machen, bei der ThymeRoot-Chain + eine lokale Quelle einzubauen... Tendenziell riecht das aber + gleich wieder nach ThymeProxy: ENTWEDER, es werden nur statische + Ressourcen für die erste Quelle der Chain und den Fallback + vorgehalten - dann könnten diese aber ebensogut (? ... Fallback + auch?!?) remote vorgehalten werden - ODER die erste Quelle und + der Fallback sind eine lokale App, die auch dynamische Inhalte + vorhält und mit ThymeRoot nur den statischen Anteil ergänzt - + dann ist man aber eigentlich schon 100% im ThymeProxy-Anwendungsfall! + * MACHT DOCH SINN: + Und zwar für den Fall, dass man basierend auf einem aus der App + gebauten Image einen eigenen Thymeroot-Container ableiten will, der + ein Fallback für das Layout mitbringt (wenn dieser Host down ist) und + bestimmte Resourcen gezielt überschreibt (favicon, Fehler-Templates...) +* Error-500 nach 404 übersetzen: https://stackoverflow.com/questions/11245932/how-to-handle-exceptions-thrown-while-rendering-a-view-in-spring-mvc +* Prefix/Suffix-Hölle sollte Vergangenheit sein! + Stattdessen zu bedenken: +* Testfall für Caching (in remote-thyme, oder hier?) + + +Thema Prefix/Suffix-Hölle: +-------------------------- +Das Rendern von Blog-Seiten funktioniert jetzt wieder _nicht_. Grund: Der aus +der URL gewonnene View-Name wird mit Prefix (/) und Suffix (.html) ergänzt, +so dass eine ungültige URL (z.B.: /blog/.html) entsteht. In dem Zusammenhang +klar geworden: Deswegen hatte ich mal alle Template-Referenzen in dem +Frontend-Projekt mit Absolutem Pfad und Suffix unkonfiguriert -- und nicht +wegen einer Änderung an ThymeProxy/ThymeRoot selbst. + +Seltsam: Warum werden die Template-Referenzen aus den HTML-Seiten auch mit +Suffix (/) und Prefix (.html) ausgestattet?!? Lösung kann eigentlich nur +sein, dass der Standard-Mechanismus sie durch den ViewResolver auflöst, was +irgendwie schräg wäre, oder die selbe Konfiguration verwendet. + +Nee! Suffix und Prefix werden wahrscheinlich gar nicht durch den ViewResolver +ergänzt, sondern durch die Konfiguration des automatisch generierten +angepassten ThymeProxy-View-Resolvers! + +Es ist Thymeleaf-Konvention, Templates ohne Prefix/Suffix zu referenzieren. +Also "pfad/name" anstatt "/pfad/name.html". Daher stammt diese Voreinstellung! + +PROBLEM IST ALSO: Wie bekommt man die URL's, die auf Blog-Ressourcen +aufgelöst werden, dazu, einen anderen Resolver zu benutzen, der kein Prefix +und Suffix ergänzt -- wobei: das würde wahrscheinlich dann auch nicht +funktionieren, weil dann Prefix/Suffix wieder bei den Template-Namen fehlen! + +LÖSUNG ALSO BISHER NUR: Doch Template-Namen inklusive Prefix/Suffix verwenden +oder den Blog dazu bekommen "/beliebiger/pfad/" auch als +"/beliebiger/pfad/index.html" oder "/beliebiger/pfad.html" entgegenzunehmen. + +Thema 404-Seiten: +----------------- +Um 404-Fehlerseiten korrekt zu rendern, muss die Exception abgefangen werden, +die Thymeleaf wirft, wenn das angeforerte nicht existiert. Leider wird diese +Exception erst ausgelöst, wenn die View gerendert wird. Daran ist ein erster +Versuch gescheitert (siehe Branch thymeroot_fix-404). Ein anderer Ansatz +wäre, die Resource-Chain, wie sie bei der Auflösung des Templates verwendet +wird, zu benutzen, um selbst zu versuchen, die View zu holen. Dafür wurden +bereits Vorbereitungen in http-resources getroffen (die konfigurierten +ResourceResolver und -Transformer wurden in einer Bean verfügbar gemacht). +Dieser Ansatz scheitert aber daran, dass die Chain-Implementierung nicht +außerhalb des Spring-Paketes instanziiert werden kann. + +Der nächste mögliche Lösungsansatz macht erst mit der nächsten Version von +thymeproxy Sinn. Da war angedacht, den angepassten Template-Resolver so +umzubauen, dass er direkt auf HttpResources zugreift, anstatt durch die +Resource-Chain zu gehen. Dies ist sinnvoll, da die Resolver/Tranformer auf +den Anwendungsfall "statische Ressourcen" zugeschnitten sind. "Nachteil" +dabei ist, das der so aufgebohrt Template-Resolver das Fallback-Verhalten, +das derzeit bequem über die Resource-Chain definiert werden kann, explizit +umsetzen muss -- also: 1.) Lokal vorhanden hat Vorrang, 2.) Remote abrufen, +falss vorhanden, 3.) Lokalen Fallback-Pfad prüfen, 4.) FEHLER + +Der so angepasste Template-Resolver könnte dann auch frühzeitig eine +aussagekräftige Exception generieren, wenn kein passendes Template +gefunden werden kann. Hier könnte dann sogar direkt eine passend +annotierte Exception verwendet werden, die das 404-Verhalten ohne weitere +Anpassungen an thymeroot auslöst. diff --git a/projects/TODO.txt b/projects/TODO.txt new file mode 100644 index 00000000..278b0f1f --- /dev/null +++ b/projects/TODO.txt @@ -0,0 +1,6 @@ +* Keine hartkodierten Links mit juplo.de im Content!! +* Links mit Version in thymeleaf-skin generieren +* ABER: Für oberste Ebene nicht?!? +* Nicht bis ins letzte Detail automatisieren: Letzte Anpassungen von Hand + (Z.B., zusätzliche/geänderte Links nachdem neue Version herausgekommen ist?) +* JSON für Menü-Generierung funktioniert nicht! -- 2.39.5