Feature Discussions

[Pierced]

Hallo,

ich sehe immer wieder an vielen Beispielen, wie wichtig es ist, Daten von Strukturknoten mit Datensätzen zu verknüpfen:

Beispielhaft sei als Anwendungsfall ein Webshop genannt, der auf der Website eingebunden werden soll und dessen Produktkategorien sich in der Navigation widerspiegeln sollen.

Wenn man nun die Artikel der entsprechenden Produktkategorie auf einer Seite anzeigen lassen möchte, hat man ganz schön Pech: Es fehlt eine Möglichkeit zur Verknüpfung zwischen Strukturknoten und Datenquellen bzw. Entities daraus.

Folgen:

• Man muss skriptuell die Struktur pflegen, um die FS_ID einer zugehörigen Produktkategorie zu pflegen
• Es gibt keine referenzielle Integrität zwischen Struktur und Datensätzen (hier: Produktkategorien)
  • Das Löschen, Ändern und Erstellen von Datensätzen spiegelt sich nicht in der Struktur wider (und umgekehrt, werden z.B. Strukturknoten gelöscht, dann hat dies keine Auswirkungen auf die Datenquellen!)
• dadurch hohe Fehleranfälligkeit, weil die Struktur-Variable jeder beliebige String sein darf

Also:

Bitte die Variablen von Strukturknoten so erweitern, dass man hier auch auf Entities von Datenquellen zugreifen kann.

PS: Es gibt sicher noch viele weitere Anwendungsfälle... das Problem tritt immer dann auf, wenn man auf einer Seite auf Elemente einer Datenquelle zugreifen will. Das soll ja relativ häufig vorkommen

[feddersen]

Ich glaube, das reicht nicht. In den Metadaten kann man ja bereits über eine entsprechende Eingabekomponenten Datensätze auswählen. Der Inhalt müsste entsprechend angepasst werden, der wesentliche Aspekt ist dann die Vererbung auf Komponentenebene, der bisher gar nicht erwähnt wird, da es bei Strukturvariablen ja bereits so funktioniert.

[Pierced]

Ich glaube den springenden Punkt "Vererbung auf Komponentenebene" haben wir hier gut herausgearbeitet.; die Überschrift habe ich gerade angepasst.

Welches weitere Vorgehen wäre zu empfehlen, damit der FReq.  bei Euch "ankommt"? Oder ist das in dieser Form ausreichend?

[hoebbel]

Interner Querverweis: TS#93148

[Peter_Jodeleit]

Welches weitere Vorgehen wäre zu empfehlen, damit der FReq.  bei Euch "ankommt"? Oder ist das in dieser Form ausreichend?
                   

Aktuell scheint es keine Fürsprecher ausserhalb deines Teams zu geben. Das könnte daran liegen, das es initial etwas 'unglücklich' aufgezogen wurde (gestartet wurde mit "Daten von Strukturknoten mit Datensätzen [..] verknüpfen", mittlerweile angelangt ist es bei "Meta-Variablen *einzeln* auf Komponenten-Ebene vererben").

Ganz allgemein gilt: Ein Feature muss genügend "Mehrwert" bieten, damit es im Produkt "ankommt".

Eine "interne ID" (wie von Holger gepostet) ist übrigens kein Indiz für irgendetwas ausser das es eine e-spirit-interne Diskussion gibt, die das Thema mindestens streift .

[Pierced]

Die Anzahl der Stimmen für (oder gegen) ein Feature kann nur ein vages Indiz für einen gewissen Mehrwert sein, nicht aber ausschlaggebendes Kriterium.

Wichtig ist, dass das Thema bei eSpirit im Produktmanagement angehört, diskutiert und darüber entschieden wird.

Natürlich habe ich ein eigenes Interesse daran, dass der FR umgesetzt wird.

Anhand der geschilderten Beispiel sollte der Hersteller allerdings schnell einsehen, dass dieser FR auch für andere Kunden einen nicht unerheblichen Mehrwert bietet (vgl. Beispiel zur Jobbörse und Problematik in unserer Projektlösung).

Da die Community eher dazu geeignet ist, Ideen einzubringen als in Entscheidungsfragen mitdiskutieren zu können, werde ich an dieser Stelle keine Energie mehr einbringen, da aus meiner Sicht nun alles zu diesem FR diskutiert wurde:

Thema ist in der Entwicklung verstanden, es gibt ein intern geführtes Ticket - alles weitere muss nun intern geklärt werden.

[Andreas-Knoor]

Kurze Ergänzung zu diesem Punkt:

Ich glaube den springenden Punkt "Vererbung auf Komponentenebene" haben wir hier gut herausgearbeitet.; die Überschrift habe ich gerade angepasst.

Ein Vererbung auf "Einzelkomponenten" in den Metadaten gibt es bereits im FirstSpirit (5.0), allerdings nur unter einer bestimmten Bedingung:

• Die konkrete Eingabekomponente darf nicht gefüllt (im Sinne von "noch niemals befüllt") sein. Beispiel: Ein Textfeld, welches einmal Inhalt enthielt und dann gelerrt wird (Leerstring) ist in diesem Kontext nicht "noch niemals befüllt", sondern mit "leer" gefüllt.

Unter dieser Bedingung kann schon eine Vererbung auf Komponentenebene realisiert werden.

Ein "Reset" der Befüllung kann z.B. über ein FS-Button mit Skript umgesetzt werden.

Vielleicht hilft dieses Wissen im Projekt schon weiter.

Was hier allerdings noch fehlt ist eine schöne Visualisierung von vererbten Inhalten (an jeder Eingabekomponente). Aktuell kann man am Formular nicht erkennen, ob ein geerbter Wert vorhanden ist oder nicht.

[hoebbel]

Hier mal ein Lösungsansatz, wie man die Visualisierung und das Leeren der entsprechenden Eingabekomponenten umsetzen kann am Beispiel einer einzelnen Textkomponente:

Formularausschnitt des MEtadatentemplates:

  <CMS_INPUT_TEXT name="meta_text" hFill="yes" noBreak="yes" singleLine="no" useLanguages="no">

    <LANGINFOS>

      <LANGINFO lang="*" label="Text"/>

    </LANGINFOS>

  </CMS_INPUT_TEXT>

  <FS_BUTTON name="delete_meta_text" onClick="script:delete_meta_data">

    <LANGINFOS>

      <LANGINFO lang="*" label="Delete meta data"/>

      <LANGINFO lang="DE" label="Metadaten entfernen"/>

    </LANGINFOS>

    <PARAMS>

      <PARAM name="meta_data">#field.meta_text</PARAM>

    </PARAMS>

  </FS_BUTTON>

Regelausschnitt des Metadatentemplates:

<!-- Default values are not recommended for meta data -->

<ON_EVENT>

  <IF>

   <EQUAL>

    <PROPERTY source="#global" name="STORETYPE"/>

    <TEXT>templatestore</TEXT>

   </EQUAL>

  </IF>

  <WITH>

   <FALSE/>

  </WITH>

  <DO>

   <PROPERTY source="delete_meta_text" name="VISIBLE"/>

   <PROPERTY source="meta_text" name="VISIBLE"/>

  </DO>

</ON_EVENT>

<!-- Value not set -->

<ON_EVENT>

  <IF>

   <NOT>

    <EQUAL>

     <PROPERTY source="#global" name="STORETYPE"/>

     <TEXT>templatestore</TEXT>

    </EQUAL>

   </NOT>

  </IF>

  <WITH>

   <NOT>

    <PROPERTY source="meta_text" name="DEFAULT"/>

   </NOT>

  </WITH>

  <DO>

   <VALIDATION>

    <PROPERTY source="meta_text" name="VALID"/>

    <MESSAGE lang="*" text="No meta data set, inheritance active"/>

    <MESSAGE lang="DE" text="Keine Metadaten gesetzt, Vererbung aktiv"/>

   </VALIDATION>

  </DO>

</ON_EVENT>

<ON_EVENT>

  <IF>

   <NOT>

    <EQUAL>

     <PROPERTY source="#global" name="STORETYPE"/>

     <TEXT>templatestore</TEXT>

    </EQUAL>

   </NOT>

  </IF>

  <WITH>

   <OR>

    <NOT>

     <PROPERTY source="meta_text" name="DEFAULT"/>

    </NOT>

    <NOT>

     <MATCHES regex="^\s*$">

      <PROPERTY source="meta_text" name="VALUE"/>

     </MATCHES>

    </NOT>

   </OR>

  </WITH>

  <DO>

   <PROPERTY source="delete_meta_text" name="VISIBLE"/>

  </DO>

</ON_EVENT>

<!-- Empty value set -->

<ON_EVENT>

  <IF>

   <NOT>

    <EQUAL>

     <PROPERTY source="#global" name="STORETYPE"/>

     <TEXT>templatestore</TEXT>

    </EQUAL>

   </NOT>

  </IF>

  <WITH>

   <OR>

    <PROPERTY source="meta_text" name="DEFAULT"/>

    <NOT>

     <MATCHES regex="^\s*$">

      <PROPERTY source="meta_text" name="VALUE"/>

     </MATCHES>

    </NOT>

   </OR>

  </WITH>

  <DO>

   <VALIDATION>

    <PROPERTY source="meta_text" name="VALID"/>

    <MESSAGE lang="*" text="ATTENTION: EMPTY value set!"/>

    <MESSAGE lang="DE" text="ACHTUNG: LEER-Wert gesetzt!"/>

   </VALIDATION>

  </DO>

</ON_EVENT>

Skript "delete_meta_data:"

import de.espirit.firstspirit.forms.FormField;

if (meta_data instanceof FormField) {

          meta_data.set(null);

}

Viele Grüsse aus Dortmund,

  Holger

[kohlbrecher]

Hallo Georg,

zu diesem Thema gibt es ein neueren Feature Request, für den allerdings mehr Votes vorhanden sind. Ich werden diesen Feature Request daher schließen und auf diesen hier verweisen.

Viele Grüße

Jan