Search the FirstSpirit Knowledge Base
Hallo,
ich habe folgendes (hoffentlich "einfach" zu lösendes) Problem in vereinfachter Darstellung:
Ich möchte für ein spezielles Eingabefeld unterschiedliche Hinweistexte einblenden, die abhängig von der eingegebenen Textlänge und einer Combobox sind.
Da die Reihenfolge der Auswertung nicht garantiert ist, steuert irgendeine Regel den Hinweistext.
Folgendes Code-Beispiel (siehe unten) zeigt mein aktuelles Problem:
Gibt man z.B: 3 Zeichen ein und wählt die Size M, könnte das Textfeld z.B. durch die definierte Regel für 'L' als valide "markiert" werden und es würde kein Hinweistext angezeigt.
Jemand eine Idee wie man so etwas sicher realisieren könnte (ggf. auch elegant)?
Ich habe jedenfalls keine Idee, wie man die Regeln widerspruchsfrei und unabhängig voneinander formulieren könnte.
Vielen Dank und beste Grüße
Daniel
Beispiel-Formular :
<CMS_MODULE>
<CMS_INPUT_TEXT name="st_text" hFill="yes" noBreak="yes" singleLine="no" useLanguages="yes">
<LANGINFOS>
<LANGINFO lang="*" label="Headline" description="Insert language specific text."/>
</LANGINFOS>
</CMS_INPUT_TEXT>
<CMS_INPUT_NUMBER name="pt_headline_counter" editable="no" length="4" singleLine="no">
<LANGINFOS>
<LANGINFO lang="*" label="Characters"/>
</LANGINFOS>
</CMS_INPUT_NUMBER>
<CMS_INPUT_COMBOBOX name="st_size" allowEmpty="no" hFill="yes" preset="copy" singleLine="no" useLanguages="no">
<ENTRIES>
<ENTRY value="s">
<LANGINFOS>
<LANGINFO lang="*" label="S"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="m">
<LANGINFOS>
<LANGINFO lang="*" label="M"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="l">
<LANGINFOS>
<LANGINFO lang="*" label="L"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="xl">
<LANGINFOS>
<LANGINFO lang="*" label="XL"/>
</LANGINFOS>
</ENTRY>
<ENTRY value="xxl">
<LANGINFOS>
<LANGINFO lang="*" label="XXL"/>
</LANGINFOS>
</ENTRY>
</ENTRIES>
<LANGINFOS>
<LANGINFO lang="*" label="Size"/>
</LANGINFOS>
</CMS_INPUT_COMBOBOX>
</CMS_MODULE>
Beispiel Regeln:
<RULES>
<ON_EVENT>
<WITH>
<ADD value="0">
<PROPERTY name="LENGTH" source="st_text"/>
</ADD>
</WITH>
<DO>
<PROPERTY name="VALUE" source="pt_headline_counter"/>
</DO>
</ON_EVENT>
<ON_EVENT>
<WITH>
<NOT>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>s</TEXT>
</EQUAL>
<GREATER_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>1</NUMBER>
</GREATER_THAN>
</AND>
</NOT>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING S: Text greater than 1 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
<ON_EVENT>
<WITH>
<NOT>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>m</TEXT>
</EQUAL>
<GREATER_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>2</NUMBER>
</GREATER_THAN>
</AND>
</NOT>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING M: Text greater than 2 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
<ON_EVENT>
<WITH>
<NOT>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>l</TEXT>
</EQUAL>
<GREATER_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>3</NUMBER>
</GREATER_THAN>
</AND>
</NOT>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING: L Text greater than 3 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
<ON_EVENT>
<WITH>
<NOT>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>xl</TEXT>
</EQUAL>
<GREATER_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>4</NUMBER>
</GREATER_THAN>
</AND>
</NOT>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING XL: Text greater than 4 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
</RULES>
Hallo Daniel,
es "gewinnt" letztlich die Kombination der einzelnen Regeln. Die EK ist z.B. insgesamt ungültig, wenn sie von mindestens einer Regel als ungültig markiert wurde. Angezeigt werden dabei immer alle Hinweistexte derjenigen Regeln, die die EK als "ungültig" markiert haben (wenn man jetzt zur Vereinfachung den scope="INFO" auch mal als "ungültig, aber macht nix" ansieht).
Der letztlich wirksame scope ergibt sich ebenso aus der Kombination, wobei der "stärkste" gewinnt: Gibt es mindestens eine Regel, wo VALID im scope SAVE auf false gesetzt wurde, kann man nicht speichern, auch wenn eine andere Regel "nur" mit scope="RELEASE" das VALID ebenfalls auf false gesetzt hat.
Letztlich war es unser Denkfehler, dass das "Setzen" der Property VALID durch eine Regel direkt die Gültigkeit der Eingabekomponente festlegt - was so eben nicht ist. Vielmehr wird dadurch erstmal nur definiert, dass die EK bezüglich dieser einen Regel als gültig oder ungültig (inkl. scope) angesehen wird. Diese Information wird durch andere Regeln auch nicht "überschrieben". Letztlich kann man es sich wie eine Liste vorstellen, die man nach der Abarbeitung der Regeln hat:
Es gilt erstmal beides parallel. Was die Auswirkung und die farbliche Hervorhebung angeht (kein Speichern=rot, kein Release=gelb), gewinnt hier die "stärkste" Restriktionsstufe.
Von daher passt Dein initiales Konstrukt schon.
Viele Grüße
Michael
Hallo Daniel,
ich bin auch kein Regelexperte, aber ich bin mir nicht sicher ob deine Regeln richtig formuliert sind.
<ON_EVENT>
<WITH>
<NOT>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>m</TEXT>
</EQUAL>
<GREATER_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>2</NUMBER>
</GREATER_THAN>
</AND>
</NOT>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING M: Text greater than 2 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
Ich vermute gerade, dass das <NOT> falsch ist. Die Regel möchte verhindern, dass Texte größer als 2 Zeichen eingegeben werden, oder?
<ON_EVENT>
<WITH>
<AND>
<EQUAL>
<PROPERTY name="ENTRY" source="st_size"/>
<TEXT>m</TEXT>
</EQUAL>
<LESS_THAN>
<PROPERTY name="LENGTH" source="st_text"/>
<NUMBER>2</NUMBER>
</LESS_THAN>
</AND>
</WITH>
<DO>
<VALIDATION>
<PROPERTY name="VALID" source="st_text"/>
<MESSAGE lang="*" text="WARNING M: Text greater than 2 characters."/>
</VALIDATION>
</DO>
</ON_EVENT>
Möglicherweise habe ich es auch missverstanden. Eventuell kann es dir auch helfen, einen ValueService zu implementieren - aber ich würde erwarten, dass man den Anwendungsfall auch mit den Regeln lösen kann.
Viele Grüße,
Lena
Hallo Lena,
vielen Dank für Deine Antwort.
Wenn Du das Beispiel mal in eine Absatzvorlage kopierst und die Formular Vorschau nutzt, sieht man das die Regeln m.E. korrekt anschlagen.
Wenn man das NOT rausnimmt wie in Deinem Beispiel dann grefit die Regel ja auch wenn der Editor z.B: Size S ausgewählt hat, oder?
Das Problem ist wohl die Reihenfolge der Auswertung, die nicht garantiert bzw. vorhersehbar ist.
Somit könnte irgendeine Regel die sich auf das gleiche Feld bezieht, genau dieses Feld wieder als valide markieren und/oder fälschlicherweise als fehlerhaft.
Genau dieses Phänomen habe ich nämlich leider derzeit in einem großem Formular mit etlichen Regeln.
Es muss also irgendeinen Weg geben die Regeln widerspruchsfrei und unabhängig voneinander formulieren zu können.
Einen ValueService würde ich ehrlicherweise gerne vermeiden 😉
Danke und Grüße,
Daniel
Hallo Daniel,
hier sollte es recht einfach mit einer Vorbedingung lösbar sein. Also im <IF> den Wert der Combobox abfragen, so dass für jeden dort wählbaren Wert nur genau eine Regel "anschlägt". Das ist mal eine der Ausnahmen, wo ein IF in Verbindung mit einer Validierung sinnvoll ist 😉
Wichtig ist nur, dass wirklich immer eine der Regeln anschlägt, damit z.B. bei 2 und S (ungültig) die EK bei Änderung auf L wieder als gültig markiert wird - dann eben durch die jetzt aktive L-Regel.
Viele Grüße
Michael
Hi Michael,
vielen Dank für Deinen Vorschlag/Idee/Lösung.
Ich werde das Anfang der nächsten Woche mal ausprobieren und mich dann wieder melden.
Besten Dank, bis bald, Grüße und ein schönes Wochenende,
Daniel
Hi Michael,
wenn ich die Vorbedingungen via IF Bedingung nutze habe ich dann nicht das Problem das ich mehrere Hinweise sehe?
Auswahl S gibt den Hinweistext für S aus.
Stelle ich dann auf 'M' um wird die M Meldung angzeigt und die S Regel greift nicht mehr (wird nicht mehr durchlaufen) und somit sehe ich dann beide Meldungen, oder!?
Viele Grüße und vielen Dank Euch,
Daniel
Hallo Daniel,
Du hast recht, die Hinweise bleiben tatsächlich stehen. Das hätte ich jetzt ehrlich gesagt anders vermutet - habe so ein Konstrukt aber auch noch nie in der Praxis ausprobiert. Hier hängt die Gültigkeit wohl tatsächlich (auch) an der konkreten Regel und ist keine nur auf eine EK bezogene Property. Wenn man länger darüber nachdenkt, kann es ja eigentlich auch gar nicht anders sein - irgendwo muss ja die Info her kommen, welche Hinweistexte an einer EK angezeigt werden oder eben nicht.
Von daher würde ich erstmal vermuten, dass Dein initiales Konstrukt so durchaus OK ist (oder funktioniert dort irgendwas nicht?). Ich frage aber bei uns intern nochmal nach.
Viele Grüße
Michael
Hallo Daniel,
ich habe nochmal nachgefragt. Es verhält sich tatsächlich so, dass das "VALID" keine direkte "Eigenschaft einer EK" ist, sondern sich vielmehr auf die Kombination "EK+Regel" bezieht. Eine EK kann also durchaus gleichzeitig bezüglich der einen Regel gültig sein und bezüglich einer anderen ungültig. Von daher müssen die Regeln bezüglich VALID nicht zwingend "widerspruchsfrei" sein.
Viele Grüße
Michael
Hi Michael,
vielen Dank für die prompten Antworten!
Wenn eine EK (Eingabekomponente?) bezüglich der einen Regel gültig sein kann und bezüglich einer anderen ungültig, wer gewinnt denn dann?
Also müssen die Regeln am Ende doch irgendwie widerspruchsfrei sein, oder?
In meinem konkreten Fall ergeben sich dann aber gefühlte unendliche Kombinationen (das tatsächliche Formular ist leider noch um Längen komplexer als mein Beispiel hier :-(). Entweder wird dann gar kein Hinweis angezeigt, oder zu viele und manchmal genau die richtige.
Am Ende ist es wohl tatsächlich am einfachsten einen allgemeinen Hinweistext auszuspielen, als Unmengen an Regeln etc. zu definieren.
Viele Grüße,
Daniel
Hallo Daniel,
es "gewinnt" letztlich die Kombination der einzelnen Regeln. Die EK ist z.B. insgesamt ungültig, wenn sie von mindestens einer Regel als ungültig markiert wurde. Angezeigt werden dabei immer alle Hinweistexte derjenigen Regeln, die die EK als "ungültig" markiert haben (wenn man jetzt zur Vereinfachung den scope="INFO" auch mal als "ungültig, aber macht nix" ansieht).
Der letztlich wirksame scope ergibt sich ebenso aus der Kombination, wobei der "stärkste" gewinnt: Gibt es mindestens eine Regel, wo VALID im scope SAVE auf false gesetzt wurde, kann man nicht speichern, auch wenn eine andere Regel "nur" mit scope="RELEASE" das VALID ebenfalls auf false gesetzt hat.
Letztlich war es unser Denkfehler, dass das "Setzen" der Property VALID durch eine Regel direkt die Gültigkeit der Eingabekomponente festlegt - was so eben nicht ist. Vielmehr wird dadurch erstmal nur definiert, dass die EK bezüglich dieser einen Regel als gültig oder ungültig (inkl. scope) angesehen wird. Diese Information wird durch andere Regeln auch nicht "überschrieben". Letztlich kann man es sich wie eine Liste vorstellen, die man nach der Abarbeitung der Regeln hat:
Es gilt erstmal beides parallel. Was die Auswirkung und die farbliche Hervorhebung angeht (kein Speichern=rot, kein Release=gelb), gewinnt hier die "stärkste" Restriktionsstufe.
Von daher passt Dein initiales Konstrukt schon.
Viele Grüße
Michael