FS_LIST Typ Database Verhalten beim Schließen des Bearbeitungsmodus

[CNoetzel]

Hallo werte Community,

wir haben folgendes Konstrukt bei uns im Einsatz:

In einer Seitenvorlage haben wir eine FS_LIST vom Typ Database, über die Datenquellen-Einträge geamacht werden können:

  <FS_LIST name="pt_stages" hFill="yes" height="250" rows="5">
    <DATASOURCE type="database" useLanguages="no">
      <ACTIONS>
        <ACTION name="NEW"/>
        <ACTION name="DELETE"/>
        <ACTION name="EDIT"/>
      </ACTIONS>
      <COLUMNS>
        <COLUMN show="no">#identifier</COLUMN>
        <COLUMN show="no">#fs_id</COLUMN>
      </COLUMNS>
      <LAYOUT>
        <ADD component="toolbar" constraint="top"/>
        <ADD component="overview" constraint="center"/>
        <ADD component="stackedview" constraint="hide"/>
      </LAYOUT>
      <TABLE>data.buehne</TABLE>
    </DATASOURCE>
    <LANGINFOS>
      <LANGINFO lang="*" label="Regionale Bühnen"/>
    </LANGINFOS>
  </FS_LIST>

Wenn jetzt ein Redakteur einen neuen Datensatz anlegt, diesen mit "Speichern" speichert aber anschließend, die Seite mit der FS_LIST nicht speichert, haben wir folgendes Phänomen:

• Der Datensatz wurde in der Quelle angelegt und ist nicht freigegeben
• Die FS_LIST enthält den Datensatz nicht, da die Bearbeitung der Seite abgebrochen wurde

Kann man dieses Verhalten irgendwie unterbinden? Wie man sehen kann, ist der ADD-Button deaktiviert. Die Redakteure haben demnach keine Möglichkeit mehr, den angelegten Datensatz der FS_LIST zuzuordnen.

Falls sich jemand fragt: Warum nutzen wir die Seite um Datenquellen-Einträge anzulegen?

Weil wir auf der Seite Meta-Angaben setzen, die beim Anlegen des Datensatzes berücksichtigt werden.

Ich bin für Tipps sehr dankbar.

Freundliche Grüße

Carsten Noetzel

[felix_reinhold]

Hallo Herr Noetzel,

das gleiche Problem haben Sie doch auch, wenn ein Redakteur einen Eintrag löscht.

Wenn eine nachträgliche Zuordnung möglich sein soll werden Sie um das Aktivieren des "ADD" Buttons nicht drum herum kommen.

Kann man dieses Verhalten irgendwie unterbinden?

Was wäre denn alternativ das gewünschte Verhalten? Das der Eintrag in der FS_LIST dennoch übernommen wird, aber alle anderen Änderungen nicht? Oder das auch beim Abbrechen immer die Änderungen gespeichert werden? Beides wird vermutlich nicht möglich sein, oder nur mit viel getrickse und kann eigentlich kein gewünschtes Verhalten sein.

Vllt. wäre ein akzeptabler Kompromiss die FS_LIST mit einer Query zu Versehen die nur Einträge des aktuellen Tages anzeigt und den ADD Button zu aktivieren.

Dann würden dem Redakteur nicht alle Einträge zur Verfügung stehen und er kann in einem solchen Fall den Eintrag "zurückholen".

Beste Grüße

Felix Reinhold

[CNoetzel]

Hallo Herr Reinhold,

gewünschtes Verhalten wäre es den Bearbeitungsmodus des Seite mit dem Datensatz zu koppeln, dass wenn die Seite nicht gespeichert wird, auch der Datensatz nicht angelegt wird. Da dies vermutlich nicht so einfach zu bewerkstelligen sein wird, habe ich auch schon über Ihre Idee mit dem ADD Button und der Query nachgedacht. Ich habe es nur bisher leider nicht geschafft den Query-Parameter via RULE in der FS_LIST zu setzen. Anscheinend ist dies noch nicht möglich in der FirstSpirit Version 5.2.312.72667. Die ODFS listet auch nur die Eingabekomponenten Combobox, Radiobutton, Checkbox und Input_List auf

Freundliche Grüße

Carsten Noetzel

[felix_reinhold]

Das wird m.E. nach nicht möglich sein. Hier würde mir nur ein SessionListener einfallen, der beim Commit des Datensatzes prüft, ob er referenziert ist und wenn nicht den Datensatz zu löschen. Hier wäre aber zu prüfen, wann dieser Commit ausgeführt wird (Vermutlich direkt bei Anlage des Datensatzes, was natürlich schlecht wäre).

"Ich habe es nur bisher leider nicht geschafft den Query-Parameter via Rule in der FS_LIST zu setzen."

Was möchten Sie denn hier als Parameter setzen? Das aktuelle Datum?

Ich hätte die Query fix hinterlegt und in der Query über TODAY alle heutigen Einträge anzeigen lassen.

Dann (falls nicht schon vorhanden) ein Datumsfeld an der Tabelle hinterlegen, dass das aktuelle Datum enthält, damit darüber gefiltert werden kann.

Dann benötigen Sie keine dynamische Query.

[CNoetzel]

Ich versuche einen einfachen String zu setzen. Meine Query sieht wie folgt aus:

<QUERY entityType="Buehne">
    <FILTERPARAM parameter="regionKuerzel" datatype="java.lang.String"/>
    <EQ attribute="region.kuerzel" parameter="regionKuerzel"/>
</QUERY>

Die Rule entsprechend (wobei pt_stages meine FS_LIST Eingabekomponente ist):

<RULES>
    <RULE>
        <WITH>
            <TEXT>EZ</TEXT>
        </WITH>
        <DO>
            <PROPERTY name="query.regionKuerzel" source="pt_stages"/>
        </DO>
    </RULE>
</RULES>

Als Exception erhalte ich:

canoet (Carsten Noetzel), session: 6741306575206777627, project: 1570189, ip: xxx.xxx.xxx.xxx
 (de.espirit.firstspirit.agency.ContentSettingsAgentImpl): de.espirit.or.MissingParameterException: regionKuerzel0
FSVersion=5.2.312.72667#3807;JDK=1.8.0_91 32bit Oracle Corporation;OS=Windows 7 6.1 x86;Date=16.03.2017 08:36:02
de.espirit.or.MissingParameterException: regionKuerzel0

Selbst wenn ich beim Property regionKuerzel0 setze, erhalte ich die Meldung. Ich tippe daher auf einen Bug in der von mir verwendeten FS Version.

[felix_reinhold]

Ich glaube wir reden hier gerade etwas aneinander vorbei 🙂

Also: Dynamisch die Query setzen geht bei der FS_LIST nicht. Mein Vorschlag bezog sich das ganze anhand eines Datums zu machen, bei dem geprüft wird, ob es sich um den heutigen Tag handelt, damit der Redakteur heute erstellte Datensätze zurückholen kann. Für diesen Anwendungsfall braucht man keine dynamische Query da FirstSpirit ja den Vergleich mit "Today" zulässt. Welches Ergebnis Sie durch das Filtern auf Regionen nun erreichen möchten kann ich leider nicht nachvollziehen.

[CNoetzel]

Hi,

ja ich bin auch leider nicht auf Ihren Vorschlag mit dem Datum eingegangen. An sich eine nette Idee, aber auch nur dann, wenn es dem Redakteur schnell auffällt, dass was schief gelaufen ist und es keine weiteren Einschränkenden Parameter gibt was bei uns leider der Fall ist. Am nächsten Tag könnte ich dann nicht den Datensatz von gestern hinzufügen.

Dann wird es wohl keine schlanke Lösung für das Problem geben, wenn ich über Regeln keine Parameter an die Query der FS_LIST übergeben kann

Freundliche Grüße

Carsten Noetzel