--- /dev/null
+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.
projects / website / commitdiff