Absatz in FS_LIST per WebEdit / ContentCreator bearbeiten

[j_mueller]

Hallo Community,

wir versuchen zur Zeit in einigen Templates die Bearbeitung im WebEdit bzw. ContentCreator zu ermöglichen.

Leider hakt es bei der FS_LIST etwas. Bisher ist es uns nicht möglich die einzelnen Absätze direkt editierbar zu machen. Zum Einsatz kommt eine Normale FS_LIST mit DATASOURCE 'inline'.

Die Ausgabe sieht nun folgendermaßen aus:

<div class="clearfix fs-list" $CMS_VALUE(editorId(target:#row.sections, editorName:"st_listing"))$>
    $CMS_FOR(s, #row.sections)$
        <div class="section" $CMS_VALUE(editorId(target:s))$>
            $CMS_VALUE(s)$
        </div>
    $CMS_END_FOR$
</div>

(Preview-Screenshot im Anhang)

Testweise habe ich im umschließenden DIV den Editor aktiviert. Durch den Parameter editorName erscheint im Popup auch nur die entsprechende FS_LIST, genau wie man es erwarten würde. (Ausnahme: Wenn man die Sprache wechselt, kommt das komplette Formular => Bug?)

Lieber wäre uns aber, wenn jeder Absatz für sich editierbar wäre, daher habe ich, wie in der Doku beschrieben, zunächst den target-Parameter gesetzt und die entsprechende Section übergeben. Leider erscheint beim Editieren das komplette Formular der Entity. Das Ergebnis ist also 'schlechter' als, wenn man den Bearbeitungsbutton der gesamten Liste anklickt. (Mit den Pametern element und editorName habe ich auch schon etwas gespielt, leider ohne Erfolg.)

Wie schon der #row Parameter erahnen lässt, befinden wir uns auf einer Detailseite mit Content-Projektion.

FS-Version: 5.1.311.65223

Wir würden uns freuen, wenn jemand einen Lösungsansatz parat hätte...

Schöne Grüße

Julius

[StefanSchulz]

Hallo Julius,

bin auch nach längerem Grübeln auf keine Idee gekommen, woran es in deinem Beispiel hakt. Kannst du mal die Java-Klasse von s ermitteln und hier posten?

Was auf jeden Fall gehen sollte, wenn der Block mit editorId() in der Vorlage definiert ist, die für die Ausgabe von s genutzt wird.

Beste Grüße

Stefan

[pavone]

Hallo Julius,

wie ist der aktuelle Stand deines Problems? Falls du noch weitere Unterstützung benötigst, solltests du Stefans Frage beantworten. Wenn du dein Problem bereits lösen konntest, wäre es gut, wenn du die Lösung hier kurz beschreiben würdest.

Viele Grüße

Tim

[j_mueller]

Hallo Stefan,

ich habe mich nun um andere Aufgaben in dem Projekt gekümmert, aber das Thema ist noch aktuell und ich habe keine Lösung.

Die Klasse von s ist:

de.espirit.firstspirit.client.access.editor.FormDataImpl

Innerhalb des Absatztemplates habe ich auch schon versucht einfach folgendes zu setzen:

<div class="fold-wrap">
  <div class="body" $CMS_VALUE(editorId())$>$CMS_VALUE(st_body, default:"")$</div>
</div>

Dann erscheint beim Hovern ein roter Rahmen ganz ohne Buttons.

Gleiches verhalten, wenn ich mir im äußeren Datenbanktemplate das Feld aus der FormData hole:

$CMS_VALUE(editorId(target:s.get(#global.language, "st_body")))$

Und auch, wenn ich in der Section #this übergebe:

$CMS_VALUE(editorId(target:#this))$

Weitere Ideen habe ich leider nicht...

Schaffst du es denn ein Datenbanktemplate mit FS_LIST und editorId() je Section aufzubauen?

Schöne Grüße

Julius

P.S.: Bei mir steht immer, dass die Frage als beantwortet angenommen wurde... Das ist aber nicht der Fall... 😉

[StefanSchulz · Accepted solution]

Hi Julius,

ich glaube, der Groschen ist gerade bei einer Diskussion mit meinem Kollegen gefallen. Versuche doch bitte mal, statt #row.sections nur sections einzusetzen. Die inneren Editoren eines Datensatzes werden innerhalb der Auswertung jeweils direkt in den Kontext gepackt und können dort ohne #row angesprochen werden. Hier erfolgt auch das Hinzufügen der nötigen Zusatzinformation, die für die editorId()-Funktion benötigt wird.

Beste Grüße

Stefan

[j_mueller]

Hi Stefan,

erstmal vielen Dank für die Antwort.

Ich verstehe jedoch nicht ganz, wie du es meinst - wobei mir gerade auffällt, dass ich vielleicht die neueste Info vergessen habe:

Der äußere Editor der Sections funktioniert mittlerweile. Es kommt also nicht das ganz Formular, sondern nur die zu editierende FS_LIST:

<div class="sections" $CMS_VALUE(editorId(view:"content_sgg", target:#row.sections, editorName:"st_listing"))$>
   $CMS_IF(!#row.sections.isEmpty())$
       $CMS_FOR(section, #row.sections)$
           <div class="contentContainer" $CMS_VALUE(editorId(target:section))$>$CMS_VALUE(section)$</div>
       $CMS_END_FOR$
   $CMS_END_IF$
 </div>

Dabei spielt es keine Rolle ob ich #row.sections oder sections verwende. Beides funktioniert nur, wenn ich den Parameter view mitgebe.

Das innere Konstrukt funktioniert nach wie vor nicht. Auch wenn ich in der inneren Vorlage (also in der Vorlage innerhalb von $CMS_VALUE(section)$) die editorIds nur mit editorName angebe, klappt es leider nicht...

Schöne Grüße

Julius

[StefanSchulz]

Hi Julius,

hast du mal geschaut, welche Klassen sections und section haben, wenn du nicht mit #row arbeitest?

Gruß

Stefan

[j_mueller]

Hi Stefan,

okay das war der entscheidende Hinweis!

Vielleicht vorher noch etwas zur Erklärung: Das Feld in unserer Datenbank heißt 'sections' (also #row.sections). Das Feld im Formular heißt 'st_listing'. (nicht fragen, historisch bedingt...)

Der Unterschied ist also:

#row.sections (db): de.espirit.firstspirit.client.access.editor.FormDataListImpl

st_listing (form): de.espirit.firstspirit.generate.IdentifiableFormDataList

Beide lassen sich loopen, die Kind-Elemente sind dann:

(db-feld): de.espirit.firstspirit.client.access.editor.FormDataImpl

(form-form): de.espirit.firstspirit.generate.IdentifiableIdProvidingFormData

Mit letzterem Funktioniert es wie es soll...

Jetzt nochmal kurz dazu, warum alles nicht früher funktioniert hat (falls jemand eine ähnlichen Projektaufbau hat):

Wir haben im System eine Datenbankvorlage namens 'content'. Das ist die Standard-Vorlage, über die wir 90% der Inhalte ausgegeben. Dort ist auch das Formular, über das die Daten gepflegt werden.

Nun haben wir einen Bereich, der vom Standard abweicht - also eine andere Ausgabe besitzt. Für den gibt es eine andere Datenbankvorlage, die sich auf die selbe Datenquelle bezieht. Diesen Bereich wollten wir jetzt über den ContentCreator Pflegbar machen. In dieser Vorlage gibt es jedoch kein Formular...

Irgendwie bin ich jetzt davon ausgegangen, dass FirstSpirit auch ohne Formular in der Lage ist den richtigen Editor zu erzeugen. Dass das rein von der Logik her so nicht ganz klappen kann, ist mir jetzt auch bewusst geworden.

Bei den anderen Feldern hat es jedoch durch Angabe der view funktioniert:

<div class="headline" $CMS_VALUE(editorId(view:"content_sgg", editorName:"cs_headline", target:#row.headline))$>
   $CMS_VALUE(if(#row.headline.empty, "<i>Überschrift</i>", #row.headline))$
</div>

Also verstehe ich das richtig, dass man bei einfachen Feldern praktisch ein beliebliges Datenbank-Template zum Rendern verwenden kann und dann durch Angabe der View zum einen die Rechte auf den Datensatz und das Template, und durch Angabe von 'editorName' das Formular-Feld und durch target das Datenbank-Feld definieren kann?

Geht das denn jetzt auch für komplexe Felder wie die FS-List?

Oder kann ich den ContentCreator generell nur verwenden, wenn mein Template ein Formular besitzt? Wie ist hier die Best Practice, wenn man mehrere Datenbankvorlagen verwenden möchte, ohne dann mehrere gleiche Formulare zu definieren? (Bei Änderungen fehleranfällig...)

Schöne Grüße

Julius