Hallo Eduard,
vielleicht noch ein Hinweis: die AdvancedUrlFactory (als Java-Klasse/Instanz) ist nicht dazu gedacht, selbst instanziiert und von eigenem Code aufgerufen zu werden. Insbesondere ist sie nicht Teil der API.
Entsprechend sind auch die Interface-Methoden dazu da, in eigenen UrlFactories implementiert (und nicht durch eigenen Code aufgerufen) zu werden. Aufgerufen werden sie dann „passend“ durch FirstSpirit selbst. Das ist auch sinnvoll, da z.B. Dinge wie Speicherung der URL oder Prüfung auf Konflikte (und in diesem Fall Ergänzung durch Postfixe) gar nicht durch die UrlFactory gemacht werden sondern vom Mechanismus „drumherum“, der bei einer direkten Nutzung der Klasse fehlen würde.
Auch wenn es sich seltsam anhört: Eine UrlFactory ist darum streng genommen gar nicht dazu geeignet die „tatsächliche“ URL eines Elements zu ermitteln, da sie erstmal nur ein „Zwischenergebnis“ bzw. einen „Wunsch“ für die URL liefert, was dann aber ggf. weiterverarbeitet wird. Die „finale URL“ entsteht letztlich immer erst im Rahmen einer Generierung.
Darum der Ansatz, hier den RenderingAgent zu nutzen, der genau diese Generierung „simuliert“ - mit einem minimalen Stück Template-Code wie $CMS_REF(…)$ - also genau der Code, der in einem Template die URL zu einem Element erzeugen würde.
Ansatz wäre hier quasi das .createRenderer(String) - also NICHT createRenderer(IDProvider)
Hier sollte sich dann auch über die entsprechenden Methoden auf dem Renderer die Konfiguration setzen lassen.
Die UrlFactory das Renderers lässt sich hier über den Public name setzen - also ohne Nutzung der eigentlichen Klasse.
Viele Grüße
Michael
