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
mbergmann
