Questions & Answers

omar
New Creator

Auf eine globale Variable im Formular zugreifen

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

 

0 Kudos
2 Replies
mbergmann
Crownpeak employee

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

0 Kudos
hoebbel
Crownpeak employee

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

Type a product name