Questions & Answers

[esstsc]

Hallo,

wir haben gerade folgendes Problem und bräuchten Hilfe bei der Herangehensweise:

Wir haben zwei Eingabefelder (aktuell FS_CATALOG) die die Daten für eine dritte Liste liefern sollen. Beispiel, man wählt Firmen (Eingabe 1) und Abteilungen (Eingabe 2) aus, dann sollen in einer dritten Listen alle Mitarbeiter der Firmen und deren ausgewählten Abteilungen angezeigt werden. Es soll aber auch Möglich sein, diese dritte Liste zu Bearbeiten (Einzelne Mitarbeiter hinzufügen oder löschen).

Kann man das über RULEs abbilden? Benötigt man ein DAP?

Gruß und Danke!

[StefanSchulz]

Hallo,

mir ist der Formularaufbau nicht so recht klar. Meinst du wirklich FS_CATALOG als Quellen oder eher die COMBOBOX?

Außer die Größe kann aktuell über Regeln keine Information eines FS_CATALOG abgefragt werden. Entsprechend wäre die Antwort auf die Frage "Nein".

Handelt es sich bei den zwei Eingabefeldern um COMBOBOXen, so können deren Werte abgefragt und in Regeln verwendet werden. Dies solle abhängig von der Listenquelle (Datensätze oder Einträge) via VALUE oder ENTRY erfolgen. Somit könnte man eine dritte Eingabekomponente (z. B. ebenfalls COMBOBOX) steuern.

Bearbeiten kann man diese dritte Liste jedoch nicht direkt. Hier bietet sich ggfs. an, einen (oder zwei) FS_BUTTON daneben zu stellen, die die gewünschten Operationen realisieren.

Ich hoffe, dies hilft ein wenig weiter. Wenn auch vermutlich eher im negativen Sinne.

Beste Grüße

Stefan

[esstsc]

Hallo Stefan,

ich meine wirklich zwei FS_CATALOG.

Wir haben jetzt als Workaround ein DAP geschrieben, dass die Inhalte als den beiden FS_CATALOG aus der Page direkt ausliest. Ganz zufrieden sind wir damit nicht, da wir im DAP den Page-Namen hart verdrahten müssen. Das gleiche gilt für die Namen der beiden FS_CATALOG.

Falls es zu diesem Vorgehen noch weitere Verbesserungsvorschläge gibt, gerne her damit.

Gruß

Steffen

[StefanSchulz]

Hi Steffen,

Sorry, mir ist das Szenario immer noch nicht ganz klar. Mit einem FS_CATALOG kann man ja nichts "auswählen" sondern lediglich neue Inhalte erstellen. Findet die Auswahl dann innerhalb der Katalogeinträge statt?

Mit dem DAP könnt ihr ja nur auf die tatsächlich gespeicherten Inhalte der Seite zugreifen, nicht auf die aktuellen Formularinhalte. Ich bin mir nicht sicher, ob das einem Redakteur klar ist. Bietet sich eventuell an, dies gegenzuprüfen.

Es ist natürlich nicht wichtig, dass ich den Aufbau verstehe. Wenn die Lösung für euch funktioniert, ist das prima. Ich frage hier rein aus Interesse nach. :smileygrin:

Beste Grüße

Stefan

[esstsc]

Hallo,

ich versuche es nochmal besser zu erklären. Bin noch recht neu bei FirstSpirit und verwende wohl nicht immer die richtigen Begriffe.

Die Redakteure sollen den FS_CATALOG mit Abteilungen und Firmen befüllen. Haben sie diese ausgewählt, werden in einer dritten "Liste" alle Kontakte angezeigt, die zu den Firmen und den Abteilungen gehören. Die beiden FS_CATALOG, Firmen und Abteilungen,  sind also nur zum Auswählen gedacht, sie sollen nicht angezeigt werden.

[StefanSchulz]

Moin.

Freue mich, jemand Neues in der FirstSpirit-Familie begrüßen zu drüfen :smileygrin:

Mich irritiert halt die Aussage bzgl. Auswählen und FS_CATALOG, weil man mit dieser Komponente selbst nur neue Inhalte erstellen kann und keine bestehenden referenzieren. Deshalb vermute ich mal, dass die Einträge der beiden Kataloge Formulare beinhalten, die wiederum die Auswahl von Objekten ermöglichen. Oder bin ich komplett auf dem Holzweg?

Gruß

Stefan

[esstsc]

Hallo,

genau so ist es

Die FS_CATALOG öffnen Absatzformulare mit denen man dann Abteilungen und Firmen auswählen kann.

Gruß

Steffen

[StefanSchulz]

Juchuh. Ich hab's verstanden

Dann passen Regeln ohnehin nicht, weil man darüber nicht auf die Inhalte eines Katalogeintrags zugreifen kann.

Je nachdem, in welchem Client das funktionieren soll, könnte man statt des DAP einen FS_BUTTON nutzen. Dieser kann direkt auf den Werten anderer Eingabekomponenten arbeiten. Der Button könnte über ein Skript ein Formular öffnen, um die Mitarbeiter auszuwählen, und diese in eine versteckte oder nicht bearbeitbare Komponente des Seitenformulars abspeichern. Dann bräuchte man keine harte Referenz auf die Seite.

Bin mir aber nicht sicher, inwieweit das im ContentCreator funktioniert.

Beste Grüße

Stefan

[frank_baus]

Hallo Stefan, danke für die Antwort bisher, das hat uns schon etwas weitergeholfen. Ich will noch einmal kurz auf das DAP zurück. Hat man die Möglichkeit diesen mit Parametern aufzurufen?  Dann könnte man überlegen diese irgendwie über ein Script zu füllen.

Gibt es irgendwo  weitere Infos zu der Sache mit dem Formular und dem Script? Grundlegend müssen wir halt eine Liste von Enities bekommen vom Typ Kontakt, gefiltert nach Firma und Abteilung. Diese sollen in dem gleichen Form ausgewählt werden und müssen dann dynamisch in diese Abfrage für die Kontakte kommen. Grüße, Frank

[StefanSchulz · Accepted solution]

Hallo Frank,

DAP: Für die FS_INDEX gibt es mehrere Wege. Über Regeln parameterisieren kann man die nur, wenn das DatasetDataAccessPlugin von FirstSpirit eingesetzt wird. Dort kann eine Query definiert und deren Parameter über Regeln (QUERY-Property) angesprochen werden. Mittels eines FS_BUTTON hat man im SiteArchitect Zugriff auf die Wertemenge der Index-Komponente und kann diese potentiell füllen. Das funktioniert aber leider im ContentCreator nicht, weil dort die Werteobjekte nicht vorhanden sind (Client-Server-Schnitt). Analoges gilt für den ValueService (Regel-Abschnitt SCHEDULE).

Formular und Script: Der FS_BUTTON ist eine Eingabekomponente und kann im Formular definiert werden. Die Fähigkeiten sind abhängig vom Client. Eine Beschreibung dazu findet ihr im ODFS (Eingabekomponente BUTTON). Mittels des Buttons wird ein Skript ausgeführt, dass dann eben auch Dialoge öffnen kann. Ein Dialog könnte beispielsweise ein Formulardialog sein.

Beste Grüße

Stefan