FS_CATALOG

FS_CATALOG (SECTION)

Die Eingabekomponente FS_CATALOG ermöglicht die Erstellung von Listen mit Absätzen oder Verweisen, sodass Redakteure mehrere Absätze bzw. Verweise direkt innerhalb eines Eingabeelementes pflegen können, ohne in eine andere Eingabekomponente, in einen anderen Absatz usw. wechseln zu müssen.

Sie übernimmt weitgehend die Funktionen der deprecateten Eingabekomponente FS_LIST, Typ INLINE. Zu einer Umstellung von FS_LIST zu FS_CATALOG siehe Migrationsleitfaden FS_LIST.

Standardmäßig bietet die Eingabekomponente dem Redakteur folgende Funktionen:

• NEW: Neuer Eintrag
• EDIT: Eintrag bearbeiten
• REMOVE: Eintrag entfernen

Einträge können auch dupliziert werden (im SiteArchitect über Kontextmenü, im ContentCreator über das Icon ).

Über diese Icons kann ein markierter Eintrag in der Liste um eine Position nach oben / unten verschoben werden. Mit einem Klick auf einen Eintrag, gedrückter Maustaste und Verschieben (Drag-and-drop) kann die Reihenfolge der Einträge ebenfalls geändert werden.

Das Deaktivieren einer oder mehrerer Funktionen (Ausnahme: Verschieben) kann über Regeln erfolgen (siehe Eigenschaften EDIT, NEW, COPY und REMOVE).
Beispiel:

<RULES>
  <RULE when="ONLOCK">
    <WITH>
      <FALSE/>
    </WITH>
    <DO>
      <PROPERTY name="NEW" source="fs_catalog"/>
    </DO>
  </RULE>
</RULES>

In diesem Beispiel wird das Anlegen neuer Einträge unterbunden. Das entsprechende Icon ist inaktiv.

Im folgenden Beispiel sind nur 3 Einträge zugelassen:

<RULES>
     <RULE>
          <WITH>
               <LESS_THAN>
                    <PROPERTY name="SIZE" source="fs_catalog"/>
                    <NUMBER>3</NUMBER>
               </LESS_THAN>

          </WITH>
          <DO>
               <PROPERTY name="NEW" source="fs_catalog"/>
          </DO>
     </RULE>
</RULES>

Die Darstellung der Elemente (Texte, Bild) im Formular wird über die Schnipsel-Definition der gewählten Absatz-/Verweisvorlagen beeinflusst.

FS_CATALOG liefert

• bei einem Zugriff über die API ein Catalog-Objekt zurück
• in Vorlagensatz- und Schnipseldefinitionen von Vorlagen hingegen ein Objekt vom Typ CatalogAccessor

Der Datentyp CatalogAccessor erbt dabei die Methoden des Datentyps Catalog.

Zu Informationen über für Drag-and-drop unterstützte Transfer-Typen siehe Seite Drag-and-drop.

Parameter

Der nachfolgenden Tabelle können die Parameter der Eingabekomponente FS_CATALOG entnommen werden.

Übersicht

name

Das Attribut "name" ist der Variablenname einer Eingabekomponente, mit dem in den Vorlagen - mit Hilfe von $CMS_VALUE()$ - das Ergebnisobjekt der Eingabekomponente verwendet oder der Inhalt ausgegeben werden kann.

Übersicht

convertEntities

Mit dem Attribut "convertEntities" werden Sonderzeichen, die in die Eingabekomponente eingegeben wurden, bei der Ausgabe in HTML-Zeichen umgewandelt.

Es gibt hier drei Ausprägungen:

• convertEntities="NONE" (Standard)
• convertEntities="STANDARD"
• convertEntities="QUOTE"

Bei NONE werden keinerlei Konvertierungsregeln angewendet.

Wird STANDARD angegeben, so werden die Konvertierungsregeln angewendet, die im Bereich "convert" der ausgewählten Konvertierungsregel des Vorlagensatzes stehen.

Die Angabe QUOTE schließt STANDARD explizit mit ein. Es wird jedoch zusätzlich der Bereich "quote" der Konvertierungsregel angewendet.

Übersicht

forbidPolyglotDataHierarchy

Über diesen Parameter kann das Verhalten mehrfach verschachtelter sprachabhängiger (Parameter useLanguages) Formulare beeinflusst werden.

Hintergrund
In früheren FirstSpirit-Versionen war es technisch möglich, FS_CATALOG und alle inneren Formulare (basierend auf vom Redakteur gewählten Absatzvorlagen, Tag TEMPLATES) sprachabhängig zu konfigurieren (entspricht useLanguages="yes", dies ist die Standardeinstellung für alle Eingabekomponenten-Typen; Eingabekomponenten in Verweisvorlagen sind hingegen grundsätzlich sprachunabhängig (useLanguages="no").
Diese Sprachabhängigkeit auf mehreren Ebenen ("altes" Verhalten) führte allerdings häufig zu Problemen hinsichtlich Übersetzungsprozessen, der Bedienbarkeit ("Usability") der Eingabekomponenten für Redakteure allgemein sowie der Wartbarkeit in der Entwicklung und auch zu Performance-Beeinträchtigungen. Inhalte, die der Redakteur eingibt, können beispielsweise (speziell auch in Kombination mit einer Verwendung der Übersetzungshilfe) in verschachtelten sprachabhängigen FS_CATALOG-Konstrukten potenziell nicht ausgegeben (z. B. Generierung) oder nachträglich bearbeitet werden. Empfohlen wurde daher die Verwendung von sprachunabhängigen Komponenten innerhalb einer sprachabhängigen FS_CATALOG-Komponente. Als Folge davon mussten Absatzvorlagen, die innerhalb einer FS_CATALOG-Komponente genutzt werden sollen, potenziell doppelt angelegt werden, einmal sprachunabhängig (zur Verwendung in einer sprachabhängigen FS_CATALOG-Komponente) und einmal sprachabhängig (zur Verwendung in allen anderen Fällen).

Dieses Schema verdeutlicht einige Nutzungsbeispiele hinsichtlich der Mehrsprachigkeit von FS_CATALOG. Die Varianten A bis D sind unproblematisch: hier wird höchstens auf einer Ebene eine sprachabhängige Komponente eingesetzt.

• In Fall A (sprachunabhängig – sprachunabhängig – sprachunabhängig) ist beispielsweise nur eine einsprachige Pflege der Inhalte möglich, das heißt, die Inhalte sind für alle Sprachen identisch.
• In Fall B (sprachunabhängig – sprachunabhängig – sprachabhängig) können die sprachabhängigen Inhalte auf der 3. Ebene für alle Sprachen parallel eingegeben werden, Register für alle Sprachen sind gleichzeitig sichtbar:
  
  In dieser Kombination ist eine mehrsprachige Pflege jedes Eintrags möglich, es handelt sich um denselben Eintrag in mehreren Sprachen.
• In Fall C (sprachunabhängig – sprachabhängig – sprachunabhängig) können Inhalte auf der 3. Ebene – je nachdem, welche Sprache auf der 2. Ebene gewählt wurde – nur zu einer Sprache eingegeben werden:
  
  In dieser Kombination ist eine unabhängige Pflege der Inhalte ("Einträge") in den einzelnen Sprachen möglich. Das heißt, für jede Sprache können Listen mit einer unterschiedlichen Anzahl an Absätzen erstellt werden.
• In Fall D (sprachabhängig – sprachunabhängig – sprachunabhängig) werden auf der 3. Ebene ebenfalls Register für alle Sprachen angeboten. Allerdings können nur sprachunabhängige ("einsprachige") Inhalte eingegeben werden:
  
  Die Sprachwahl erfolgt auf der ersten Ebene.
  In dieser Kombination ist ebenfalls eine unabhängige Pflege der Inhalte ("Einträge") in den einzelnen Sprachen möglich. Das heißt, für jede Sprache können Listen mit einer unterschiedlichen Anzahl an Absätzen erstellt werden.

Lösung
Ab FirstSpirit-Version 5.2R5 wird für Projekte, die mit FirstSpirit-Version 5.2R5 oder höher neu erstellt werden, standardmäßig die Verwendung sprachabhängiger Eingabekomponenten auf Ebenen innerhalb einer sprachabhängigen FS_CATALOG-Komponente unterbunden ("neues" Verhalten). Sprachabhängige Eingabekomponenten in Vorlagen, die innerhalb einer ebenfalls sprachabhängigen FS_CATALOG-Komponente verwendet werden, werden von FirstSpirit automatisch als sprachunabhängig behandelt. Somit werden die Nachteile des alten Verhaltens ausgeräumt.

Das alte Verhalten ist nicht empfohlen und wird in Zukunft wahrscheinlich nicht mehr unterstützt. Eine Migration wird empfohlen.

Kompatibilität
Für Projekte, die bei einem Upgrade des Servers von einer früheren Version auf FirstSpirit-Version 5.2R5 übernommen werden oder die per Projektimport von einem Server mit einer früheren Version von FirstSpirit auf einem Server mit FirstSpirit-Version 5.2R5 importiert werden, wird das alte Verhalten (Sprachabhängigkeit auf mehreren Ebenen) bis auf Weiteres weiterhin unterstützt.
Um Projekte aus früheren FirstSpirit-Versionen auf eine Verwendung des neuen Verhaltens vorzubereiten, wurde u.a. der Parameter forbidPolyglotDataHierarchy mit folgenden Ausprägungen eingeführt:

• no: Die Sprachabhängigkeit von Formularen, die über diese FS_CATALOG-Komponente referenziert werden ("innen"), wird gemäß ihrer Definition in der Vorlage berücksichtigt (useLanguage="yes" / useLanguage="no", "altes" Verhalten). Dies ist die Standardeinstellung.
• yes: Es wird nur die Sprachabhängigkeit der aktuellen FS_CATALOG-Eingabekomponente ("außen") berücksichtigt. Sprachabhängigkeit in Vorlagen, die über diese FS_CATALOG-Komponente referenziert werden ("innen"), wird ignoriert, alle inneren Eingabekomponenten werden automatisch als sprachunabhängig (useLanguages="no") interpretiert. Inhalte in diesen inneren Eingabekomponenten können dann automatisch nur noch einsprachig eingegeben und gespeichert werden.
  Ist für die aktuelle FS_CATALOG-Eingabekomponente useLanguages="no" definiert, wird für die nächste Eingabekomponente einer referenzierten Absatzvorlage, für die eine mehrsprachige Wertespeicherung zugelassen ist, diese Sprachabhängigkeit berücksichtigt, alle inneren Formulare ab dieser Komponente werden hingegen als sprachunabhängig (useLanguages="no") interpretiert.

Die Datenhaltung zwischen altem und neuem Verhalten ist unterschiedlich. Werden in einem Projekt sprachabhängige Komponenten innerhalb einer sprachabhängigen FS_CATALOG-Komponente verwendet, müssen die Daten der FS_CATALOG-Komponente geprüft und ggf. gesichert bzw. angepasst werden, bevor forbidPolyglotDataHierarchy="yes" für die FS_CATALOG-Komponente verwendet werden kann. Ohne Prüfung und Sicherung kann die Verwendung von forbidPolyglotDataHierarchy="yes" zu Datenverlust im Projekt führen: Sind bereits Inhalte in einer FS_CATALOG-Komponente bzw. in inneren Formularen dieser Komponente vorhanden, so werden nach dem Speichern der FS_CATALOG-Komponente die Inhalte in der Sprache beibehalten, die gerade vom Redakteur bearbeitet wurde (Fallback: Mastersprache); waren Inhalte in anderen Sprachen vorhanden, so entfallen diese. Eine Migration beim Setzen von forbidPolyglotDataHierarchy="yes" erfolgt also erst mit dem Speichern der Eingabekomponente.

Hinweis: Über die Projekteinstellungen im FirstSpirit ServerManager ("FirstSpirit ServerManager – Projekt – Eigenschaften – Kompatibilität – FS_CATALOG: Verschachtelung sprachabhängiger Eingabekomponenten") oder per FirstSpirit Developer-API kann dieses Verhalten für alle FS_CATALOG-Vorkommen in einem Projekt zentral beeinflusst werden (siehe dazu FirstSpirit Dokumentation für Administratoren, Kapitel Kompatibilität (→Dokumentation für Administratoren)). Der Parameter forbidPolyglotDataHierarchy wird nur ausgewertet, wenn unter "FS_CATALOG: Verschachtelung sprachabhängiger Eingabekomponenten" für das betreffende Projekt die Option "Zugelassen" eingestellt ist bzw. die Methode getForbidPolyglotDataHierarchy() den Wert false liefert.

Übersicht

height

Mit dem Parameter height wird die Anzeigehöhe der Eingabekomponente festgelegt. Als Wert erwartet der Parameter eine Ganzzahl.
Die hier gewählte Zahl gibt, basierend auf dem initialen Anzeigemodus der Eingabekomponente (siehe Parameter viewMode), die Anzahl der Zeilen an, die in der Komponente komplett sichtbar sind. Darüber hinaus wird noch ein Teil einer weiteren Zeile sichtbar gemacht, um Benutzern anzuzeigen, dass die Eingabekomponente noch mehr Einträge beinhält.

Der Standardwert ist 4.

Übersicht

hidden

Mit dem Parameter "hidden" kann eine Eingabekomponente für den Redakteur ausgeblendet werden.

Bei der Angabe von hidden="YES" wird die Eingabekomponente ausgeblendet, bei hidden="NO" nicht.

Der Standardwert für hidden ist NO, so dass Eingabekomponenten standardmäßig für den Redakteur sichtbar sind.

Übersicht

preset

Mit dem Attribut preset kann festgelegt werden, wie Vorgabewerte in einer Eingabekomponente behandelt werden (vgl. dazu auch Kapitel Vorgabewerte). Wird preset="default" gesetzt, wird der im Formular definierte Rückgriffwert verwendet. Nachträgliche Änderungen im Formular an diesem Wert wirken sich auf alle Verwendungen in den vom Redakteur gepflegten Eingabekomponenten aus, solange bis ein manueller Wert in die Eingabekomponente gesetzt wird. Dies ist die Standardeinstellung. Wird preset="copy" gesetzt, wird der durch den Redakteur gewählte Wert "hart" in der Eingabekomponente gespeichert. Nachträgliche Änderungen am Vorgabewert im Formular wirken sich nicht aus.

Übersicht

searchRelevancy

Mithilfe dieses Parameters kann definiert werden, mit welcher Gewichtung Inhalte dieser Eingabekomponente in Suchergebnissen angezeigt werden (SiteArchitect: Globale Suche (Globale Suche (→Handbuch FirstSpirit SiteArchitect)), Suche in Datenquellen (Suche (→Handbuch FirstSpirit SiteArchitect)) | ContentCreator: Suche im Report-Bereich). So kann beispielsweise festgelegt werden, dass Suchtreffer in Überschriften prominenter in den Suchergebnissen angezeigt werden als Suchtreffer in Fließtexten. Andererseits können auch Eingabekomponenten ganz von der Suchindizierung ausgenommen werden, was in einer erhöhten Performanz der Indizierung resultieren kann.
Für diese Konfiguration der Suche stehen folgende Werte für eine Gewichtung zur Verfügung:

• none: Der Inhalt einer mit diesem Attribut versehenen Eingabekomponente wird nicht indiziert. Seiten, Absätze und Datensätze, die Inhalte enthalten, die in auf diese Weise konfigurierten Eingabekomponenten gespeichert sind, werden nicht als Suchtreffer angezeigt. Eine Suche nach in solchen Komponenten gespeicherten Inhalten per Drag-and-drop ist nicht möglich ("Das Feld kann nicht für die Suche verwendet werden, da es als nicht relevant markiert ist."). Solche Felder sind auch in der "Einfachen Suche" in Datenquellen entsprechend markiert ("Kann nicht durchsucht werden.").
• default: Der Inhalt der Eingabekomponente wird mit normaler Gewichtung indiziert. Hierbei handelt es sich um die Standardeinstellung.
• high: Der Inhalt einer mit diesem Attribut versehenen Eingabekomponente wird mit erhöhter Gewichtung in Suchergebnissen angezeigt (Ausnahme: Suche nach Datensätzen). Das heißt, ist der Suchbegriff sowohl in einer Eingabekomponente enthalten, die mit searchRelevancy="high" versehen ist, als auch in einer Eingabekomponente, die mit searchRelevancy="default" versehen ist, wird ein Suchtreffer, der in der Eingabekomponente mit searchRelevancy="high" gespeichert ist, an höherer Position in den Suchergebnissen angezeigt.

Wird der Parameter nicht angegeben, wird die Eingabekomponente für den Suchindex normal gewichtet (searchRelevancy="default").

Auswertungshierarchie:

• Ist für diese Eingabekomponente ("außen") searchRelevancy="none" konfiguriert,
  • werden Eingabekomponenten von inneren Einträgen nicht indexiert, unabhängig von den searchRelevancy-Einstellungen der Eingabekomponenten der für innere Einträge verwendeten Vorlagen.
• Ist für diese Eingabekomponente ("außen") searchRelevancy="default" konfiguriert,
  • werden Eingabekomponenten in inneren Einträgen, für die searchRelevancy="none" gesetzt ist, nicht indexiert,
  • werden Eingabekomponenten in inneren Einträgen, für die searchRelevancy="default" gesetzt ist, bei der Indexierung normal gewichtet,
  • werden Eingabekomponenten in inneren Einträgen, für die searchRelevancy="high" gesetzt ist, bei der Indexierung höher gewichtet.
• Ist für diese Eingabekomponente ("außen") searchRelevancy="high" konfiguriert,
  • werden Eingabekomponenten in inneren Einträgen, für die searchRelevancy="none" gesetzt ist, nicht indexiert,
  • werden Eingabekomponenten in inneren Einträgen, für die searchRelevancy="default" oder searchRelevancy="high" gesetzt ist, bei der Indexierung höher gewichtet.

Hinweis: Auch Kennsätze (Register Schnipsel von Vorlagen, Feld "Kennsatz") werden indiziert. Wird für eine Eingabekomponente die Suchrelevanz auf none gesetzt (searchRelevancy="none") und der Inhalt gleichzeitig als Kennsatz in der Schnipsel-Definition der Vorlage verwendet, so wird das entsprechende Objekt dennoch gefunden.

Siehe auch

• Seite Suche und Indizierung
• Interface GomSearchRelevancy (Package de.espirit.firstspirit.access.store.templatestore.gom, FirstSpirit Access-API)
• Interface SearchService (Package de.espirit.firstspirit.access.search, FirstSpirit Access-API)
• Interface QueryAgent (Package de.espirit.firstspirit.agency, FirstSpirit Access-API)

Übersicht

useLanguages

Mit dem Parameter useLanguages kann festgelegt werden, ob eine Eingabekomponente für verschiedene Sprachen unterschiedliche bzw. abweichende Werte speichern soll oder nicht (mehrsprachige Pflege).

Wird der Parameter nicht angegeben so werden standardmäßig abweichende Werte für die verschiedenen Sprachen gespeichert.

Bei der Angabe von NO (...useLanguages="NO") wird ein Wert für alle Sprachen gespeichert.

Ab FirstSpirit-Version 5.2R5 wird useLanguages="YES" potenziell nicht mehr berücksichtigt. Siehe dazu Parameter forbidPolyglotDataHierarchy (FS_CATALOG).

Übersicht

viewMode

Über diesen Parameter kann die initiale Anzeige der Einträge in dieser Eingabekomponente gesteuert werden.

• DETAILS: Detailansicht der Einträge. Dies ist der Standardwert.
  
  
  
• HEADERS: Listenansicht der Einträge.
  
  
  
• SYMBOLS: Es werden nur Symbole angezeigt.
  
  
  

Beispiel:

viewMode="HEADERS"

Die Darstellungsweise kann in jeder Eingabekomponente vom Redakteur selbst gewählt werden.

Übersicht

LANGINFOS

Über das Tag LANGINFOS können für jede Eingabekomponente sprachabhängige Angaben definiert werden, z. B. wie die Eingabekomponente in den unterschiedlichen Projektsprachen betitelt sein soll (Parameter label), welcher Tooltip angezeigt werden soll (Parameter description) usw. Aus Gründen der Übersichtlichkeit werden dabei Definitionen, die in mehreren Sprachen identisch sind, zusammengefasst. So wird z. B. aus

 <LANGINFOS> 
 <LANGINFO lang="*" label="Date" format="dd.MM.yy"/>
 <LANGINFO lang="DE" label="Date" format="dd.MM.yy"/>
 <LANGINFO lang="EN" label="Date" format="MM/dd/yy"/>
</LANGINFOS>

beim Speichern

 <LANGINFOS> 
 <LANGINFO lang="*" label="Date" format="dd.MM.yy"/>
 <LANGINFO lang="EN" label="Date" format="MM/dd/yy"/>
</LANGINFOS>

Die Definition für den Rückfallwert (*) bleibt dabei immer erhalten, von Definitionen für Sprachen mit gleichen Werten bleibt immer die oberste erhalten.

Ab FirstSpirit-Version 4.2R4 kann der Rückfallwert weggelassen werden. Dann wird beim Speichern automatisch die zuerst definierte Sprache als Rückfallwert verwendet, z. B. wird aus

<LANGINFOS>
 <LANGINFO lang="EN" label="Date"/>
 <LANGINFO lang="DE" label="Datum"/> 
</LANGINFOS>

beim Speichern

 <LANGINFOS> 
 <LANGINFO lang="*" label="Date"/>
 <LANGINFO lang="DE" label="Datum"/> 
</LANGINFOS>

LANGINFO

Mit dem Tag LANGINFO werden Werte oder Attribute für eine Sprache oder aber für die Verwendung als Rückfallwerte angegeben.

Um Werte bzw. Attribute für eine Sprache anzugeben ist im Parameter lang die Abkürzung der Projektsprache anzugeben:

...
<LANGINFO lang="DE".../>
...

Rückfallwerte werden mit dem speziellen Sprachkürzel * ("für alle Sprachen") angegeben:

...
<LANGINFO lang="*".../>
...

Bei dem Parameter lang handelt es sich um einen Pflichtparameter.

Übersicht

lang

Mit dem Parameter lang wird das Sprachkürzel, das in den Servereigenschaften im Feld Abkürzung eingetragen ist (siehe Sprach-Vorlagen (→Dokumentation für Administratoren)), angegeben, um festzulegen, für welche Projektsprachen die Definitionen gelten sollen, z. B. DE für Deutsch, EN für Englisch, FR für Französisch usw. Folgende Zeichen können dabei beliebig oft angegeben werden: -, _, 0-9 und A-Z. Kleinbuchstaben werden nach dem Speichern der Vorlage automatisch in Großbuchstaben umgewandelt. Alternativ kann * für Rückfallwerte verwendet werden.

Übersicht

description

Über den Parameter description kann eine Beschreibung angegeben werden, wie die Eingabekomponente vom Redakteur verwendet und befüllt werden soll. Der hier definierte Text wird als Tooltip bei Mouse-Over an der betreffenden Eingabekomponente eingeblendet.

Der Text soll dem Redakteur als Hilfestellung dienen und so kurz wie möglich, verständlich und relevant sein. Er sollte zum Label (Parameter label) passen bzw. dieses geeignet ergänzen.
Achten Sie darauf, dabei Terminologie zu verwenden, die der Redakteur kennt und erwartet.

Beispiel:

...description="Bitte geben Sie hier den Text für die Überschrift ein (H1)."...

Tipp: Wenn Sie wissen möchten, wie Sie Redakteure beim Befüllen von Eingabekomponenten noch besser unterstützen und anleiten können, schauen Sie sich das Kapitel zu Regeln sowie weitere Parameter und Funktionen von Formularen an.

Übersicht

label

Mithilfe des Parameters label definieren Sie das Label (die Beschriftung) der Eingabekomponente.

Wählen Sie ein möglichst kurzes und aussagekräftiges Label.
In Verbindung mit einer relevanten Beschreibung (Parameter description) können Sie den Redakteur darin unterstützen, die Eingabekomponente korrekt und erfolgreich zu verwenden.

Beispiel:

... label="Überschrift (H1)" ...

Übersicht

TEMPLATES

Über das Tag TEMPLATES wird angegeben, welcher Vorlagentyp auswählbar sein soll.

Darüber hinaus kann über dieses Tag die Menge der in der Eingabekomponente verwendbaren Absatz- bzw. Verweisvorlagen festgelegt werden. Dazu wird das Tag TEMPLATE verwendet. Eine verwendbare Absatz- oder Verweisvorlage entspricht einem TEMPLATE-Tag, z. B.

<TEMPLATES type="section">
 <TEMPLATE uid="simple_value_with_anchor"/>
</TEMPLATES>

Übersicht

type

Mit dem Parameter type wird der Vorlagentyp in doppelten Hochkommata angegeben, der auswählbar sein soll.

Dazu stehen die Variablen SECTION und LINK zur Verfügung: Wird type="SECTION" gesetzt, kann aus den Absatzvorlagen des Projektes gewählt werden, wird type="LINK" gesetzt, kann aus den Verweisvorlagen des Projektes gewählt werden.

Übersicht

TEMPLATE

Mit einem TEMPLATE-Tag wird genau eine Vorlage des über das Tag TEMPLATES angegebenen Vorlagentyps definiert, die in der Eingabekomponente auswählbar sein soll.

Wird kein TEMPLATE-Tag angegeben, können alle Vorlagen des über das Tag TEMPLATES definierten Typs ausgewählt werden.

Das Tag besitzt den Pflichtparameter uid, der den eindeutigen Bezeichner der Vorlage enthalten muss.

Übersicht

uid

Für den Pflichtparameter uid ist ein gültiger Referenzname einer Vorlage anzugeben.

Dabei ist der Vorlagentyp zu berücksichtigen, der über den Parameter type im Tag TEMPLATES, angegeben wurde: Ist type="LINK" definiert, können für uid nur Referenznamen von Vorlagen angegeben werden, die sich in der Vorlagenverwaltung im Unterordner "Verweisvorlagen" befinden. Ist type="SECTION" definiert, können für uid nur Referenznamen von Vorlagen angegeben werden, die sich in der Vorlagenverwaltung im Unterordner "Absatzvorlagen" befinden.

Übersicht

PositiveInteger	Positive Ganzzahl
Designator	Eindeutiger Bezeichner variabler Länge; muss mit einem Buchstaben oder Unterstrich beginnen und darf nur die Zeichen "A-Z", "a-z", "0-9" und "_" enthalten, z.B. "fr_st_varName"
Relevancy	Definition einer Gewichtung für die Suche NONE Irrelevant für die Suche DEFAULT Normale Gewichtung HIGH Hohe Gewichtung
Preset	Behandlung von Vorgabewerten Copy Verwendung des vom Redakteur gewählten Wertes, nachträgliche Änderungen wirken sich nicht aus Default Verwendung des im Formular definierten Rückgriffwerts, solange kein manueller Wert gesetzt wird
ViewMode	Anzeige-Modus für Einträge DETAILS Detailansicht der Einträge HEADERS Listenansicht der Einträge SYMBOLS Nur Symbole
String	Eine beliebige Zeichenkette
TemplateType	Auswählbarer Vorlagentyp SECTION Es können Absatzvorlagen ausgewählt werden. LINK Es können Verweisvorlagen ausgewählt werden.
ConvertEntity	Schalter, um die Konvertierungsregel festzulegen NONE Keine Konvertierungsregeln anwenden STANDARD Konvertierungsregeln des "convert"-Bereichs anwenden QUOTE Konvertierungsregeln des "convert"- und "quote"-Bereichs anwenden
YesNo	Schalter, um ein Attribut anzuwenden oder nicht NO Attribut nicht anwenden YES Attribut anwenden
LanguageAbbreviation	Sprachkürzel, z.B. DE, EN, FR oder * für Rückfallwerte

Beispiele

1) Konfigurationsbeispiel FS_CATALOG

Ein Beispiel für die Eingabekomponente FS_CATALOG (Absatzliste):

<FS_CATALOG name="BEZEICHNER" useLanguages="NO">
      <LANGINFOS>
        <LANGINFO lang="*" label="TEXT_FALLBACK" description="TEXT_FALLBACK"/>
        <LANGINFO lang="DE" label="TEXT_DE" description="TEXT_DE"/>
        <LANGINFO lang="EN" label="TEXT_EN" description="TEXT_EN"/>
      </LANGINFOS>
      <TEMPLATES type="SECTION"/>
 </FS_CATALOG>

2) Beispiel für ein Inhaltsverzeichnis

Mithilfe von FS_CATALOG, Typ SECTION, kann für eine Art Inhaltsverzeichnis am Anfang einer Seite über folgende Syntax eine Liste der Absätze erstellt werden:

$CMS_FOR(entry, st_cal)$
                <a href="#toc_$CMS_VALUE(#for.index)$">Section $CMS_VALUE(#for.index + 1)$</a><br/>
$CMS_END_FOR$

In der Absatzvorlage, die vom Redakteur ausgewählt wird, sollte folgende Syntax als Verweisziel (Anker) ergänzt werden:

<a id="toc_$CMS_VALUE(#index)$" name="toc_$CMS_VALUE(#index)$"></a>

Siehe auch das Beispielprojekt.