Questions & Answers

[aVogt]

Hallo,

ich stelle gerade die "CMS_INPUT_CONTENTLIST" auf die "FS_LIST" um.

Die sieht dann wie folgt aus:

    <FS_LIST name="cs_ListFAQ" height="230" rows="8">
      <DATASOURCE type="database" useLanguages="yes">
        <ACTIONS>
          <ACTION name="ADD"/>
          <ACTION name="REMOVE"/>
          <ACTION name="UP"/>
          <ACTION name="DOWN"/>
          <ACTION name="GOTO"/>
        </ACTIONS>
        <COLUMNS>
          <COLUMN show="no">#identifier</COLUMN>
        </COLUMNS>
        <LAYOUT>
          <ADD component="toolbar" constraint="top"/>
          <ADD component="overview" constraint="center"/>
          <ADD component="stackedview" constraint="hide"/>
        </LAYOUT>
        <TABLE>FAQ.bereich</TABLE>
      </DATASOURCE>
      <LANGINFOS>
        <LANGINFO lang="*" label="Auswahl der FAQ-Bereiche"/>
      </LANGINFOS>
  </FS_LIST>
 
Die Pflege in der Box funktioniert.

Zu der Ausgabe im HTML-Kanal habe ich eine Frage:

$CMS_FOR(myFAQB, cs_ListFAQ)$
...
$CMS_VALUE(myFAQB.Gebiet)$ // Gebiet ist ein Feld in der Tabelle Bereich
...
$CMS_END_FOR$

Das funktioniert nun leider nicht mehr.

myFAQB ist vom Typ de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormData, das steht nicht in der API.

Nach einigem Suchen und propieren funktioniert dieser Weg:
$CMS_VALUE(myFAQB.entity.Gebiet)$
Warum funktioniert jedoch $CMS_VALUE(myZG.fs_id)$?

Ist es richtig, dass man das "entity" zwischenfügen muss, oder gibt es einen anderen Weg? In der Doku habe ich zur Ausgabe der FS_LIST nichts gefunden (oder überlesen).

Es ist auch egal wo ich die FS_LIST definiere und ausgebe (z.B. direkt in einer Absatzvorlage und dort auch ausgebe oder in den globalen Einstellungen und dann in einer Seitenvorlage darauf zugreife).

Grüße

Andreas

[andre]

> myFAQB.Gebiet

Gebiet ist hier der Spaltenname der Tabelle, richtig?

es muesste aber der name/identifier der gemappten Komponente dieser spalte sein

EntityFormData ist kein API , das API-Objekt ist FormData

http://www.e-spirit.com/odfs42/access/de/espirit/firstspirit/forms/FormData.html

[aVogt]

> myFAQB.Gebiet

Gebiet ist hier der Spaltenname der Tabelle, richtig?

Das ist richtig.

Das wäre dann:

$CMS_VALUE(myFAQB.get(#global.language,"cs_bezeichnung").get())$

Das ist aber bedutend länger als:

$CMS_VALUE(myFAQB.entity.Gebiet)$

und liest sich m.M. auch schlechter, da man manchmal aus derFeldbezeichnung nicht auf die Spalte schließen kann (Designfehler meinerseits).

Kann/darf ich denn auch die Variante mit "entity" verwenden? Die FS_LIST ist sprachunabhängig. Also muss ich nicht auf die Sprache achten.

[Peter_Jodeleit]

Das funktioniert nun leider nicht mehr.

myFAQB ist vom Typ de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormData, das steht nicht in der API.

Implementierungklassen stehen generell nicht in der API. Das Vorgehen ist immer: Komponente in der Dokumentation lokalisieren (hier FS_LIST) und dort den Absprungpunkt in die API vom Wertetyp. Dies führt hier zu FormData.

FormData stellt die Properties aus dem Formular zur Verfügung, während CMS_INPUT_CONTENTLIST den Werte-Typ Entity hatte, das die Properties der Tabelle bereitstellt. Wenn Formularname und Attributname nicht übereinstimmen, muss man das Template auf anpassen. Und die Zugriffe auf den Formularnamen anpassen.

Das von dir verwendete Attribut "entity" ist keine API, d.h. dein Workaround muss in zukünftigen Versionen nicht funktionieren.

[EDIT]

Mir wurde nur das Ursprungsposting angezeigt (caching-Problem in Jira?)

Post einfach ignorieren...

[andre]

was auch reichen sollte:

$CMS_VALUE(_myFAQB.cs_bezeichnung)

[aVogt]

Danke, dass sieht schon besser aus.

Eine Anmerkung habe ich trotzdem noch:

Wir haben eine Tabelle "FAQ" und eine zugehörige Tabelle "FAQBereich".
In der Tabellenvorlage "Programmbereich" gibt es nur ein einzelnes Textfeld.
In der Tabelle "FAQ" gibt es eine "CMS_INPUT_LIST" in der die "FAQBereich" ausgewählt werden können.

Bei einer  Ausgabe gehe ich nicht von "FAQ" sondern vom "FAQBereich" aus.
Und zwar: gib alle "FAQ" zu dem "FAQBereich" aus. Da nun in der Vorlage für den "FAQBereich" nur ein Textfeld steht, musst ich ein zusätzliches Hidden-CMS_INPUT_LIST einfügen.
Das ist war kein Problem aber aus meiner Sicht ein unnötiges Feld.
(Und falls die "CMS_INPUT_LIST" mal abgelöst werden sollte muss das auch geändert werden.)

Daher war ich bestrebt über den Feldnamen in der Datenbank zu gehen.

Grüße
Andreas

[andre]

> Kann/darf ich denn auch die Variante mit "entity" verwenden?

der entity-Zugriff sollte nicht verwwendet werden. Und jederzeit wegfallen.

grüsse

andré

[aVogt]

ok schade (dachte ich mir schon fast).

Leider funktioniert mein o.g. Ansatz leider nicht.

Wenn ich  in der FAQBereich auch eine CMS_INPUT_LIST anlege und dann über den KomponentenNamen zugreife, kann ich über die so erhaltene Liste iterieren, erhalte aber als Elemente ein "de.espirit.firstspirit.store.access.contentstore.ContentOptionFactory$ContentOption". Das nutz mir nichts (zumindest habe ich bisher eine Entity erhalten und habe dann auf des DB-Feld zugegriffen)

Wenn ich die CMS_INPUT_LIST durch eine FS_LIST ersetze, kann ich wieder darauf zugreifen.

Dann hab ich in den zwei Vorlagen unterschiedliche Eingabekomponenten die in ein DB-Feld schreiben.

FAQ - CMS_INPUT_LIST

FAQBereich - FS_LIST

Das ist doch sicher ungünstig, oder?

Somit müsste ich in der FAQ auch auf CMS_INPUT_LIST umstellen, aus einer CMS_INPUT_LIST lassen sich aber die daten besser auswählen.

[andre]

das API-Objekt von ContentOption ist Option und Option#getValue sollte dann das Entity liefern.

[andre]

> Das ist doch sicher ungünstig, oder?

ja, sehr