Prinzessin
I'm new here

Abhängig von Combobox-Eintrag GUI-Element über Rules ein-/ausblenden a

Jump to solution

Hallo, ich habe in den Datenquellen ein Formular mit zwei Eingabefeldern:
- Combobox mit Werten
- Textfeld (hidden = yes)

<CMS_MODULE>

<CMS_INPUT_COMBOBOX name="cs_typ" useLanguages="no">
<ENTRIES>
<ENTRY value="">
<LANGINFOS>
<LANGINFO lang="*" label="none"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="big_teaser">
<LANGINFOS>
<LANGINFO lang="*" label="Big teaser"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="hotspot">
<LANGINFOS>
<LANGINFO lang="*" label="Hotspot"/>
</LANGINFOS>
</ENTRY>
</ENTRIES>
<LANGINFOS>
<LANGINFO lang="*" label="Viewport type" description="Please choose the viewport type."/>
</LANGINFOS>
</CMS_INPUT_COMBOBOX>

<CMS_INPUT_TEXT name="cs_headline" hFill="yes" hidden="yes" singleLine="no" useLanguages="yes">
<LANGINFOS>
<LANGINFO lang="*" label="Headline" description="Insert the headline."/>
</LANGINFOS>
</CMS_INPUT_TEXT>
....

Ich habe nun eine Regel definiert, dass das Element cs_headline nur eingeblendet wird, wenn der Eintrag "big_teaser" in der Combobox gewählt wurde:


<RULES>
<ON_EVENT>
<WITH>
<NOT>
<EQUAL>
<PROPERTY source="cs_typ" name="VALUE"/>
<TEXT>big_teaser</TEXT>
</EQUAL>
</NOT>
</WITH>
<DO>
<PROPERTY source='cs_headline' name='VISIBLE'/>
</DO>
</ON_EVENT>
</RULES>

Leider funktioniert diese Regel nicht. Weiß jemand, was hier nicht passt?

1 Solution

Accepted Solutions

<RULES>

    <ON_EVENT>

           <WITH>

               <NOT>

                <EQUAL>

                         <PROPERTY source="cs_typ" name="ENTRY"/>

                         <TEXT>big_teaser</TEXT>

                     </EQUAL>

               </NOT>

        </WITH>

           <DO>

            <PROPERTY source='cs_headline' name='VISIBLE'/>

           </DO>

      </ON_EVENT>

</RULES>

Ich habe die Erfahrung gemacht, dass FirstSpirit 5 die Logik der Boolschen Algebra manchmal innerhalb seiner Regeln einfach umkehrt. Probier das doch einfach mal aus.

View solution in original post

0 Kudos
11 Replies
StefanSchulz
I'm new here

Hi,

die Eigenschaft "VALUE" liefert für eine Combobox keinen Text sondern eine Option als Objekt. Für eine textuelle Prüfung steht die Eigenschaft "ENTRY" zur Verfügung (seit Version 5.0.105), mit der sich obige Regel realisieren lässt. Diese Eigenschaft liefert den Schlüsselwert für (festkodierte) Einträge einer Combobox.

Gruß

Stefan

0 Kudos

Hallo,

meinen Sie das so:

(das funktioniert leider nicht)

<RULES>

    <ON_EVENT>

           <WITH>

                <EQUAL>

                    <PROPERTY source="cs_typ" name="ENTRY"/>

                    <TEXT>big_teaser</TEXT>

                </EQUAL>

        </WITH>

           <DO>

            <PROPERTY source='cs_headline' name='VISIBLE'/>

           </DO>

      </ON_EVENT>

</RULES>

0 Kudos

<RULES>

    <ON_EVENT>

           <WITH>

               <NOT>

                <EQUAL>

                         <PROPERTY source="cs_typ" name="ENTRY"/>

                         <TEXT>big_teaser</TEXT>

                     </EQUAL>

               </NOT>

        </WITH>

           <DO>

            <PROPERTY source='cs_headline' name='VISIBLE'/>

           </DO>

      </ON_EVENT>

</RULES>

Ich habe die Erfahrung gemacht, dass FirstSpirit 5 die Logik der Boolschen Algebra manchmal innerhalb seiner Regeln einfach umkehrt. Probier das doch einfach mal aus.

0 Kudos

Yvonne Neubauer schrieb:

Hallo,

meinen Sie das so:

(das funktioniert leider nicht)

<RULES>

    <ON_EVENT>

           <WITH>

                <EQUAL>

                    <PROPERTY source="cs_typ" name="ENTRY"/>

                    <TEXT>big_teaser</TEXT>

                </EQUAL>

        </WITH>

           <DO>

            <PROPERTY source='cs_headline' name='VISIBLE'/>

           </DO>

      </ON_EVENT>

</RULES>

Genau so sollte es aber funktionieren. Und, Nein Smiley Wink, wir kehren die Boolsche Algebra nicht um. Wenn das berechnete Ergebnisobjekt eine Wahrheitsaussage ermittelt, dann wird der Wert auch so weiterbenutzt.

Können Sie mir die genaue Versionsnummer der eingesetzten FS-Version? Ich nehme an, dass es um den Desktop-Client geht.

Gruß

Stefan

0 Kudos

Nicht umgekehrt?

Warum greift in meinem Fall dann

<WITH>

  <NOT>

        <PROPERTY source="st_pictureSize" name="EMPTY"/>

    </NOT>

  </WITH>

  <DO>

  <VALIDATION>

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

                <MESSAGE lang="*" text="Picture size must have a value."/>

                <MESSAGE lang="DE" text="Die Bildgröße muss ausgewählt werden."/>

  </VALIDATION>

  </DO>

, sobald st_pictureSize eben leer ist? In meinem Verständnis eine Umkehrung der Logik.

0 Kudos

Leider weiß ich nicht, was mit "greifen" gemeint ist. Der Logik nach wird durch die Regel "st_pictureSize" dann als Valide markiert, wenn die Komponente nicht leer (als befüllt) ist (ich vermute mal, eine Zahl eingegeben wurde). Ist dem nicht so?

Gruß, Stefan

0 Kudos

Das Feld ist nur dann valide, korrekt und von FS zu akzeptieren, wenn es NICHT leer ist.  Nur scheint bei der Entwicklung der Regellogik irgendwie übergangen worden zu sein, dass man nach bisherigem Vorgehen in sämtlichen (!) Programmiersprachen simple WENN WAHR DANN - Konstrukte aufbaut. In unserem ganzen Entwicklerteam hatte es Zeit gekostet, das Über- oder Umgehen dieses Prinzips zu verinnerlichen und verwirrt meiner Meinung nach vollkommen unnötig.

Es handelt sich übrigens um eine Combobox.

0 Kudos

Ja. Tut mir leid, dass ich das Problem immer noch nicht verstehe. Die Regel ist doch genau äquivalent zu der Aussage: WENN NICHT feld = leer DANN feld := valide. Nur, dass es sich hier nicht um ein Wenn-Dann-Konstrukt handelt, sondern dass der Ausdruck prinzipiell mächtiger/generischer ist, weil darüber auch nicht-boolesche Werte verarbeitet werden können. (Deshalb auch WITH-DO und nicht IF-THEN.)

Ist jetzt vielleicht wirklich ein wenig Off-Topic geworden. Eventuell besteht hier aber auch (noch) ein Defizit in den durchgeführten Schulungsmaßnahmen (dynamische Formulare/Regeln sind ja noch neu).

Gruß, Stefan

0 Kudos

Ja, das Thema ist Off-Topic, aber ich finde es trotzdem mal ganz interessant zu erfahren, warum mann sich eben dazu entschlossen hat, das so zu implementieren. Denn so wie ich - und Andere, die mit mir entwickeln - den oberen Auszeichnungscode verstehen, setzt der DO-Teil genau dann ein, wenn das Feld eben nicht leer ist. Wie gesagt, vom reinen Leseverständnis aus betrachtet.

Meiner Meinung nach ist diese Implementierung ganz einfach am Nutzer bzw. Entwickler vorbeigegangen, somit alles Andere als praxisorientiert.

0 Kudos