Search the FirstSpirit Knowledge Base
Guten Tag Zusammen,
Wir haben in einem Formular einer Vorlage ein FS_INDEX, wobei mittels DatasetDataAccessPlugin eine Datenquelle angebunden wird. In dem FS_INDEX wird auch ein Query (analog zu dem Beispiel unten) benutzt, um die Daten in dem FS_INDEX zu filtern.
Meine Frage wäre dann, ob es möglich wäre, den Parameter (name) auf eine globale Variable, die in der Projekteinstellung liegt, anstatt der Konstante zuzuweisen. Falls das nicht direkt geht, gibt es vielleicht einen Umweg, wobei man das am Ende irgendwie schafft.
Beispiel:
<QUERY name="Products.names>
<PARAM name="name">DS%</PARAM>
</QUERY>
Danke und viele Grüße,
Omar
Hallo Omar,
wenn es sich nicht um einen FS_INDEX sondern um eine INPUT_LIST oder INPUT_CHECKBOX handeln würde, wäre eine Idee, hier eine RULE zu nutzen, die den Query Parameter setzt (siehe hier unter „Exception: setting dynamic values using a database query“) und zwar in Verbindung mit dem FormDataValueService, um an den Wert aus den Projekteinstellungen zu kommen. Soweit ich weiß, geht das dynamische Setzen des Query-Parameters aber beim FS_INDEX nicht (wobei ich es allerdings auch noch nie versucht habe).
Falls es eine Option ist, den FS_INDEX zu ersetzen, wäre das eine Überlegung wert. Insbesondere wenn der FS_INDEX im Rahmen einer Tabellenvorlage genutzt und auf eine „zu-n“-Relation gemappt ist, wäre das „migrationstechnisch“ sogar kompatibel.
Alternativ fällt mir noch die Variante ein, das „manuelle“ Bearbeiten des FS_INDEX per RULE zu verbieten, und ihn stattdessen über einen eigenen kleinen „Wizard“ (Aufruf per FS_BUTTON) zu befüllen hinter dem ein Script/Executable mit einem entsprechenden Formular steckt (das dann wieder eine CHECKBOX/LIST beinhaltet und den oben beschriebenen Mechanismus nutzt) und die gewählten Einträge dann in den INDEX „überträgt“. Wäre etwas aufwändiger und von der Benutzung auch nicht ideal, aber ggf. eine Alternative.
Viele Grüße
Michael
Hallo Omar,
man kann auch die Query für eine FS_INDEX Eingabekomponente dynamisch ändern.
ABER man muss dafür sorgen, dass das Query ohne die Anpassung die ausgewählten Datensätze als gültig ansieht, sonst gibt es Folgeprobleme!
Beispiel für eine entsprechende Query:
<QUERY entityType="...">
<FILTERPARAM parameter="fakeId" datatype="java.lang.Integer" value="2147483647"/>
<FILTERPARAM parameter="..." datatype="java.lang.String" value="..."/>
<OR>
<LTE attribute="fs_id" parameter="fakeId"/>
<EQ attribute="..." parameter="..."/>
</OR>
<ORDERCRITERIA attribute="..."/>
</QUERY>
Die Regeln dazu würden dann so aussehen:
<RULE>
<SCHEDULE delay="0" id="dynamic_index_query" service="FormDataValueService">
<PARAM name="UID">
<PROPERTY name="PAGE_UID" source="#global"/>
</PARAM>
<PARAM name="UIDTYPE">
<TEXT>PAGESTORE</TEXT>
</PARAM>
<PARAM name="FIELD">
<TEXT>...</TEXT>
</PARAM>
<PARAM name="LANGUAGE">
<TEXT>DE</TEXT>
</PARAM>
</SCHEDULE>
<DO>
<PROPERTY name="query.myParam" source="..."/>
</DO>
</RULE>
<RULE when="ONLOCK">
<WITH>
<NUMBER>-1</NUMBER>
</WITH>
<DO>
<PROPERTY name="query.fakeId" source="..."/>
</DO>
</RULE>
Erklärung:
Im Query werden alle Datensätze erlaubt, indem als ID eine sehr hohe ID vergeben wird. Ohne Anpassung, kann man also alle Datensätze auswählen, da die Bedingungen ja mit einem OR verknüpft sind. Beispielsweise bei der Generierung ist also sichergestellt, dass alle Datensätze als gültig angesehen werden.
Die erste Regel ändert nun die eigentliche Abfrage so, dass nur die gewünschten Datensätze erlaubt sind.
Die zweite Regel ändert den fake Teil der Abfrage so, dass keine Datensätze mehr erlaubt sind (es gibt keine fs_ID < 0)
Unschön, setze ich aber so seit längerem ohne Probleme ein.
Viele Grüße
Holger