• Thomas Pollinger
• 29.07.2019
• DE

RenderTags: Parent vs. MainLink

Das Template Rendering kennt zwei Modelle, welche sich bei der Verwendung der verfügbaren Objekte, Eigenschaften und Methoden unterscheiden. Es gibt das Template Rendering für Content und Navigation. Dabei gibt die Regel, dass man alle Objekte, Methoden und Eigenschaften im Modus "Navigation" hat, jedoch bei "Content" alles bis auf "Navigation" zur Verfügung steht.

Das erklärt dann auch wann man .Parent. bzw. .MainLink. verwenden kann. Denn .Parent. ist eine Eigenschaft des Objektes Index und das steht nur innerhalb der Navigation zur Verfügung. Die Eigenschaft .MainLink. steht bei dem Objekt .Page. zur Verfügung, welches man aber auch über den Navigationsindex erreichen kann.

Beispiele

Abfrage des übergeordneten Navigationsindex- bzw. Page-Objekt, von der aktuellen Position innerhalb des Navigationsindex über die Navigation Manager Content-Klassen:

<%!! Context:CurrentIndex.Parent.Page.Id !!%>

und jetzt eine Abfrage innerhalb einer regulären Content-Klasse (Seite):

<%!! Context:CurrentPage.MainLink.OwnerPage.Id !!%>

 

Erläuterung

Bei der Abfrage innerhalb des Navigationsindex, gibt es derzeit eine fixe Regel:

Eine Instanz (Seite) einer Content-Klassen (Typ MasterPage) darf nur
an einer Stelle innerhalb der Navigationsstrukur verknüpft sein.

Damit ist es sehr einfach und eindeutig, welches Index- bzw. Page-Objekt das s.g. Eltern-(Parent)-Objekt ist. Hierbei stellt der Navigations Manager diese Regel sicher und kümmert sich um die Bereitstellung der notwendigen Objekte inkl. Methoden und Eigenschaften.

Syntax:

<%!! Context:CurrentIndex.Parent.Page.Id !!%>

 

Bei der Abfrage innerhalb des Content, also außerhalb des Navigations Manager, gibt es folgende Regel:

Eine Instanz (Seite) einer Content-Klassen (Typ Page) kann an
mehreren Strukturelementen verknüpft oder verwiesen sein.

Nun wird eine Ermittlung der s.g. Elternseite schon etwas schwerer. Warum?! Das ist relavtiv einfach beantwortet: Wenn eine Seite an mehr als einem Strukturelement verknüpft ist, gibt es eine 1:n Beziehung zwischen der Seite und mehreren Eltern. Weil man dies nicht, aus sicht der verknüpften Seiten, aufgelöst bekommt - gibt es den s.g. Hauptlink (Mainlink) um damit eine Verknüpfung als primäres Elternteil zu definieren.

Syntax:

<%!! Context:CurrentPage.MainLink.OwnerPage.Id !!%>

Aus diesem Grund ist und wird es nicht möglich sein, mit der Eigenschaft .Parent. das Eltern Element im Modus "Content" zu ermitteln.

 

Hinweise

Bei uns im Slack gab es dazu eine interessante Diskussion zu diesem Thema, im Kontext Verweise und Hauptlink. Auf die Frage:

Gibt es eigentlich ein .Parent also in etwa Context:CurrentPage.Parent oder Context:CurrentPage.ParentPage? Denn über Mainlink erhält man immer den Hauptlink und das ist leider nachteilig, wenn eine Seite mehrfach verknüpft ist.

sind wir auf folgende zusammengefasste Antwort gekommen:

• RenderTags und Navigation kennen nur den Hauptlink, Mehrfachverlinkungen werden ignoriert.
• Verweise von Strukturelementen kommt für das nächste Release (16.7.x).
• Die Implementierung wird dann diese Verweise korrekt auflösen.
• Funktionen wie über Verweise nicht hinauspublizieren werden hier aber nicht funktionieren, weil der Link den Regeln des Hauptlink unterliegt.
• Das Ziel wird also korrekt sein, aber die URL wird stets die vom Hauptlink der verwiesenen Seite sein.

 

Siehe auch

• OpenText™ | RenderTags
• Objekte: Die Basis der RenderTags
• Content: Möglichkeiten und Verfügbarkeit
• Navigation: Möglichkeiten und Verfügbarkeit
• Navigation: Ausgabe der Navigationbereiche
• RenderTags: MainLink & OwnerPage
• RenderTags: LinkName
• RenderTags: GetLinkedContents()

---

Über den Autor: