Feature Discussions

[Anonymous]

Nutzt man oft gleiche Eingabeformulare in ähnlichen Kontexten (beispielsweise eine FS_LIST zum Referenzieren eines Datenbank-Entities oder ein Medium eines bestimmten Ordners per FS_REFERENCE), so hat man duplizierten Formular-Code an etlichen Stellen im Projekt.

Soll das Formular angepasst werden führt das unweigerlich zu sehr viel Copy-Paste-Arbeit und ist anfällig dafür, dass die Anpassung bei einem der Formulare vergessen wird.

Es wäre gut Formularcode auszulagern und ähnlich zu CMS_RENDER von Formattemplates verschachteln zu können:

<FS_REFERENCE name="cs_medium" hFill="yes" upload="yes" useLanguages="no">

  <FILTER>

    <ALLOW type="picture"/>

  </FILTER>

  <LANGINFOS>

    <LANGINFO lang="*" label="Medium" description="Medium für diesen Beitrag"/>

  </LANGINFOS>

  <PROJECTS>

    <LOCAL name=".">

      <SOURCES>

        <FOLDER name="images" store="mediastore"/>

      </SOURCES>

    </LOCAL>

  </PROJECTS>

</FS_REFERENCE>

zu etwas wie

<CMS_FORM_TEMPLATE name="media_from_images_folder" />

[bIT_sosswald]

Hallo mmarm,

der absolute Klassiker für diesen Anwendungsfall ist für mich folgendes Beispiel:

• Verschiedene Seitenvorlagen im Projekt:
  • Homepage
  • Standardseite
  • Suchseite
  • Produktgruppenseite
  • etc.
• Diverse Standardwerte die auf den Seiten gepflegt werden sollen:
  • Title
  • Description
  • href-lang
  • og-MetaTags
  • Tracking-Tags
  • Stage mit Bilder, Slides, Texten, etc.
  • etc.

Diese müssen im Formular auf jeder Seitenvorlage integriert werden.

Kommt ein neues Feld hinzu, muss dies auf allen Seitenvorlagen nachgezogen werden. Kommt eine neue Seitenvorlage hinzu, müssen dort alle Felder ins Formular eingebaut werden etc.

Grüße

Sandro

[mmarm]

Hallo Sandro,

danke für deinen Input! Ich habe dazu noch eine Nachfrage: Wenn ich dich richtig verstehe geht es dir hier zusätzlich darum eine ganze Gruppe an Eingabekomponenten wiederzuverwenden, also nicht (nur), bzw. hier anstelle die einzelnen Komponenten, korrekt?

Viele Grüße

Matthias

[bIT_sosswald]

Hallo Matthias,

ich verstehe deine Rückfrage nicht so ganz. Aber ja, für das Beispiel von Seitenvorlagen gibt es ein ganzes Set an Eingabekomponenten mit entsprechender Konfiguration (Regeln, Mehrsprachigkeit, etc.) die auf allen Seiten wiederverwendet werden sollen. - Also ja, eine Gruppe an Komponenten.

Aber man könnte das natürlich auch auf eine einzelne Komponente runterbrechen, wenn man z.B. die Auswahl von Bildern generell nur aus einem Remote-Media Projekt aus einem speziellen Ordner zulassen möchte. Dann könnte man die FS_REFERENCE Komponente einmal entsprechend konfigurieren und dann überall wiederverwenden.

Grüße

Sandro

[mmarm]

Hallo Sandro,

ich möchte die konkreten Anwendungsfälle sammeln. Deinen Anforderung könnte man ja unterschiedlich verstehen bzw. umsetzen (natürlich nur auf der Metaebene, wie dann Referenzen umgesetzt sind ist ja dann auch noch eine (ganz entscheidende ) Frage):

so:

• Seitenvorlage A
  • EK 1
  • EK 2
  • EK 3
  • EK 4
• Seitenvorlage B
  • Ref EK 1
  • Ref EK 2
  • Ref EK 3
  • EK 5
• Seitenvorlage B
  • Ref EK 1
  • Ref EK 2
  • Ref EK 3
  • EK 6

oder so:

• Seitenvorlage A
  • Gruppe A
    • EK 1
    • EK 2
    • EK 3
  • EK 4
• Seitenvorlage B
  • Ref Gruppe A
  • EK 5
• Seitenvorlage C
  • Ref Gruppe A
  • EK 6

Mit den Referenzen einzelner Komponenten wird bestimmt schon einiges erschlagen, gleichzeitig muss natürlich dann trotzdem jede Seite angepasst werden wenn eine neue "globale" EK dazu kommt.

Allerdings ist dann vielleicht eine Umsetzung im Produkt der Einzelreferenzen leichter als das mit den Gruppen (oder andersrum).

Deshalb möchte ich alle Fälle weitergeben, auch wenn sie nicht alle umgesetzt werden.

Viele Grüße

Matthias

[mseyfarth]

Hallo Matthias,

unser Anwendungsfall ist recht ähnlich zu bIT.sosswald​, betrifft aber vor allem Absatzvorlagen.

2 Beispiele:

1.

Wir verwenden bei uns sehr häufig 3 Eingabekomponenten für die Speicherung von Bilder (Desktop, Tablet und Mobil).

Also nicht die Auflösungen der Medien.

Das wir in den Templates nicht immer diese drei Eingaben einbauen müssten wäre es also elegant man könnte diese in eine Eigenständige Absatzvorlage auslagern und in die Pflegemaske rein Rendern

Nach dem Motto:

<CMS_FORM_TEMPLATE name="some_name" ref_template="absatz_vorlage_x_y" />

Die Absatzvorlage "absatz_vorlage_x_y" beinhaltet dann die 3 Eingabekomponenten.

Dieses Prinzip (oder ähnlich) gibt es ja schon bei Verweisvorlagen mit Linkeditors.

2.

Wir verwendeten dafür eine FS_LIST, in +- 80 Absatzvorlagen wo Tracking-Parameter für sämtliche Links gepflegt werden konnten.

Durch die Umstellung auf FS_CATALOG mussten wir alle diese Stellen manuell anpassen was unfassbar viel Zeit gekostet hat.

Mit dem selben Prinzip wie aus Beispiel 1 hätten wir viele Stunden Arbeiten sparen können.

Wunsch für die Ausgabe im, z.B. HTML Kanal.

Derzeit erfolgt die Ausgabe immer $CMS_VALUE(eingabeKomponente)$

oder bei Listen $CMS_VALUE(eingabeKomponente.item.whatever)$

Nach der aktuellen Logik müsste das obige Konzept wie folgt ausgegeben werden

$CMS_VALUE(some_name.eingabeKomponente)$

oder bei Listen $CMS_VALUE(some_name.eingabeKomponente.item.whatever)$

Ich weiß nicht, wie es andere Entwickler sehen, aber ich finde es sehr reizvoll, wenn man diesen Schritt nicht bräuchte.

Also das die Ref "some_name" implizit aufgelöst wird, sodass man direkt auf die dahinter liegende Eingabekomponenten zugreifen kann.

Also das folgendes weiter funktioniert. Dadurch müsste auch die Auflösung / Regelanwendung einfach zu implementieren sein ohne eine Verschachtelung berücksichtigen zu müssen.

$CMS_VALUE(eingabeKomponente)$

oder bei Listen $CMS_VALUE(eingabeKomponente.item.whatever)$

Gruß

Matthias

[mmarm]

Hi Matthias,

auch dir vielen Dank! Klingt für mich so, als ließe sich das mit den bisherigen Anforderungen auch abbilden. Ob eine Wiederverwendung auf Seitentemplate oder Absatztemplate Ebene passiert ist wahrscheinlich für eine mögliche Umsetzung eher ein untergeordnetes Thema.

Ich nehme es trotzdem mal mit ins interne Dokument auf.

Viele Grüße

Matthias

[mfinsterbusch]

Hi Matthias,

unserer Haupt-Anwendungsfall sind 'Standard- Komponenten', die über Layout und Anzeige entscheiden und somit in (fast) allen Templates vorkommen. Sowas wie, Zeitsteuerung, Auswertung device, Auswertung time- constraints, layouts.

Sind in Summe um die 10 Komponenten. Führen wir hier etwas neues ein, müssen wir das auf allen Absatz Tempates ausrollen.

besten Gruß,

Maik

[mseyfarth]

Liebes e-spirit-Team,

diese wunderbare Anfrage der Community feiert inzwischen (seit 4 tagen) seinen 7. Geburtstag...

Gibt es zu diesem Feature, welches seit jeher die meisten Stimmen hat (von über 700 Feature Requests), einen Zwischenstand / Roadmap?

Gruß

Matthias

[LukasGoebel]

Hallo zusammen,

schon wieder sind über eineinhalb Jahre vergangen, seit das Thema zum ersten Mal offiziell von mmarm aufgegriffen wurde. Auch in unserem Projekt würde das ein absolut essenzielles Feature darstellen.

Deshalb nochmal eine freundliche Nachfrage, wie es denn mit den Planungen diesbezüglich aussieht. Hat sich seit letztem Jahr etwas in diese Richtung getan?

Viele Grüße,
Lukas

[Tim_Rother]

Hallo Community,

wie in unsere ersten Product Office Hour angekündigt, wollen wir uns weiterhin um eure Feature Requests kümmern . Es gibt dafür ein internes Team, welches sich regelmäßig trifft, die Wünsche bespricht und bewerten lässt. 

Bei dem hier gewünschten Feature würde es sich insgesamt um massive Eingriffe in FS handeln, die eine 1:1 Umsetzung nicht wirklich darstellbar machen. Da wir den use-case aber 100% nachvollziehen können, prüfen wir andere Möglichkeiten, wie wir hier mehr Convenience zur Verfügung stellen können. 

Sobald ich mehr dazu sagen kann, melde ich mich wieder.

Viele Grüße

Tim