Hallo Marcus,
alternative (auch nicht besonders schöne bzw. etwas aufwendige) Lösung - bzw. zumindest eine grobe Idee:
Im Linktemplate (das in dem das FS_DATASET mit den drei Content2s ist), eine weitere Eingabekomponente (nennen wir sie mal lt_moreInfo) definieren. Da gibt es mehrere Varianten, was das für eine sein kann, siehe weiter unten.
Dann einen FS_BUTTON im Linktemplate einbauen mit einem zugehörigen Skript (sprich: Executable im Modul, Beanshell-Skript ist ja eher ungünstig). Dem FS_BUTTON gibt man dann als Parameter die "nötigen" Dinge mit. Das wären auf jeden Fall mal die beiden Eingabekomponenten lt_dataset und lt_moreInfo (und später ggf. noch weitere Steuerungsparameter).
So ungefähr:
<FS_BUTTON
name="BEZEICHNER"
icon="media:BEZEICHNER"
style="FIRSTSPIRIT"
onClick="class:MyMagicExecutable"
useLanguages="NO"
hFill="YES">
<LANGINFOS>
...
</LANGINFOS>
<PARAMS>
<PARAM name="datasetField">#field.lt_dataset</PARAM>
<PARAM name="moreInfoField">#field.lt_moreInfo</PARAM>
</PARAMS>
</FS_BUTTON>
Das hinterlegte Executable hat vollen (auch schreibenden!) Zugriff auf die Werte der übergebenen EKs (die kommen dort als FormFields an) , d.h. ist nicht an die Regeln gebunden und unterliegt auch nicht deren Einschränkungen bzgl. Serialisierung.
Die Idee ist jetzt, im "MyMagicExecutable" eine Art Wizard zu bauen (Stichworte FormsAgent, ShowFormDialogOperation usw.), der eine Auswahlmöglichkeit der im verlinkten Datensatz vorhandenen "inneren Absätze" bietet. Z.B. einfach als Combobox die man sich "on the fly" über den FormsAgent anhand der Daten aus dem verlinkten Datensatz baut.
Dazu brauchst du aber außerdem noch irgendeine Info, aus welchen inneren Absätzen man wählen können soll - sprich: in welcher Spalte bzw. welcher Eingabekomponente des Datensatzes der Wizard den Catalog überhaupt findet. Dass du hier verschiedene Datenquellen hast, macht es nicht einfacher (siehe weiter unten...). Auch wenn die Spalten bzw. EKs zufällig gleich heißen, würde ich den Namen nicht hart codieren. Das wäre sonst ein contract, an den sich in einem Jahr keiner mehr erinnert. Darum müsstest du hier wohl eine Art Mapping-Info bauen (Zuordnung Datenquellen-UID zu EK-Name) und das dem FS_BUTTON als weiteren Parameter übergeben, in etwa als
<PARAM name="content2catalogNameMapping>blog=tt_blogContent;stellenangebote=tt_jobInfos</PARAM>
Das heißt, bis dahin kommst du schonmal an die Daten ran und hast auch eine Auswahlmöglichkeit des "inneren Absatzes". Nur was damit machen?
Hier kommt dann die weitere Eingabekomponente ins Spiel. Sie ist dazu gedacht, dass das MyMagicExecutable das "innere Linkziel" aus dem Auswahl-Schritt darin speichert - das wäre im Fall eines CATALOGs letztlich der identifier der Card.
Für diese weitere EK "lt_moreInfo" gibt es jetzt mehrere Varianten die mir einfallen:
a) Einfach und funktional
Im einfachsten Fall nimmst du ein INPUT_TEXT im Linktemplate dafür, in das du die UUID der Card einfach rein schreibst (natürlich per Regel auf readonly).
Vorteil: Einfach zu bauen
Nachteil: Der Redakteur sieht hier nicht wirklich auf was er verlinkt, bis er den Wizard öffnet. Zumindest ich kann mir UUIDs eher schlecht merken...
b) Komplizierter aber schön(er...)
Theoretisch könntest du auch ein INPUT_LINK nehmen und erst da drin die Zusatzinfos in einem "inneren Linktemplate" speichern. Denn Linktemplates können Schnipsel haben.
Wenn da jedoch wieder nur ein INPUT_TEXT drin ist, bringt das nicht viel - denn Schnipsel können nicht "nach außen" greifen. Du würdest ja eine "kombinierte" Anzeige von Datensatz-Titel und Titel/Überschrift des inneren Absatzes haben wollen.
Von daher würde ich in dem Fall (wenn es dir den Aufwand wert ist) im eigentlichen Linktemplate (in dem vorher das lt_dataset war) erstmal ein INPUT_LINK machen und dann in dessen innerem Linktemplate das lt_dataset und das INPUT_TEXT. Dann hättest du im "äußeren" Linktemplate wenn ich es jetzt richtig durchdacht habe die Möglichkeit, ein einigermaßen ansehnliches Snippet zu basteln.
Vorteil: Schicker für den Redakteur (er sieht bei schlauem Snippet z.B. die Überschrift des inneren Absatzes).
Nachteile: Redakteur muss im CC ein oder zwei mal mehr Klicken. Außerdem recht aufwendig bzw. fummelig zu bauen und vor allem eine Umstrukturierung des Linktemplates (Datenmigration falls es schon benutzt wird usw).
Die Ausgabe müsstest du dir dann noch passend bauen - und zwar einmal an der Stelle wo der Link gerendert wird. Das einfachste wäre wohl ein #HIER_DER_IDENTIFIER hinter dem Link, der schon auf die richtige Seite leitet. Außerdem musst du sicherstellen, dass in der Zielseite entsprechende Anker ausgegeben werden. Das ist aber kein Hexenwerk.
Garnierungsmöglichkeiten:
- Per Regel sollte sichergestellt werden, dass der Button nur aktiv ist, wenn ein Datensatz ausgewählt wurde (EDITABLE sollte da für den Button gehen).
- Es wäre schön, wenn bei einem bereits vorhandenen Eintrag und erneutem Aufruf über den Button das aktuell (in den Daten, d.h. in der EK lt_moreInfo) gespeicherte Element / Absatz auch schon ausgewählt ist
Was (wie Florian schon angemerkt hat) eher ungünstig ist: Die Möglichkeit hier im FS_DATASET mehrere Datenquellen wählen zu können. Vor solchen Konstrukten warne ich immer eher, denn es sind ja fachlich verschiedene Dinge die im Laufe der Zeit dann doch auseinander laufen (auf einmal soll ein Link auf ein Stellenangebot weitere Steuerungsmöglichkeiten haben usw...). Irgendwann hat man dann "Monster-Linktemplates". Lieber mehrere Linktemplates (eines für jede Ziel-Datenquelle). Dann müsstes du auch kein "Mapping-Info" mehr bauen, sondern einfach nur einen PArameter der direkkt den Namen des FS_CATALOGs im Datensatz enthält.
Nachträglich Umbauen ist da aber natürlich schwierig.
Grundsätzliche Nachteil(e):
Es gibt keine Möglichkeit der Validierung bzw. zu verhindern, dass ein innerer Absatz (streng genommen ist es kein Absatz sondern ein "nacktes" FormData) gelöscht wird, wenn es noch "benutzt" wird. Das geht grundsätzlich nicht über die Regeln, da man denen das FS_DATASET nicht mitgeben kann. Zumindest nicht im CC.
Ich hoffe, ich habe dich jetzt nicht erschlagen... 😉
Viele Grüße
Michael
. Wie sehen die "Absätze" des Datensatzes aus? Sind die pro Blogeintrag (Stellenangebot, Presse) unterschiedlich? Falls nein, dann könnte vielleicht die folgende Idee weiterhelfen:
