Questions & Answers

[nilsweber]

Für unseren internen Auftraggeber sollen Hinweise auf Pflichtfelder erst bei Betätigung des Speichern-Buttons erscheinen, idealerweise als Hinweisfenster oder notfalls auch unterhalb der Eingabekomponenten. Besonders wichtig ist die Darstellung im WebClient, da dieser bevorzugt bzw. ausschließlich redaktionell genutzt werden soll.

Es wurde deshalb ausdrücklich die betreffenden Eingabekomponenten nicht mit

allowEmpty="false"

deklariert sondern versucht über z.B. folgendes Regelkonstrukt das Feedback erst zum Speicherzeitpunkt zu geben:

<ON_SAVE>
        <WITH>
            <NOT>
                <PROPERTY source="cs_headline" name="EMPTY"/>
            </NOT>
        </WITH>
        <DO>
            <VALIDATION>
                <PROPERTY source="cs_headline" name="VALID"/>
                <MESSAGE lang="*" text="Bitte Headline vergeben!"/>
            </VALIDATION>
        </DO>
    </ON_SAVE>

Doch leider funktioniert obige Regel letztlich genauso als ob ich eben allowEmpty="false" verwendet hätte, nimmt also eine Validierung vor Speicherung vor. Frage: mache ich was falsch, ist dieses (merkwürdige) Verhalten von ON_SAVE gar erwünscht (wenn ja, warum?) oder liegt evtl. ein Fehler vor?

danke für Hilfe,

Nils Weber

[mbergmann · Accepted solution]

Hallo Nils,

das ist genau so beabsichtigt und auch sinnvoll. Der Redakteur bekommt hier ein direktes Feedback an der Stelle, wo er gerade arbeitet. Eine erst nachträgliche Fehlermeldung würde auch in einem größeren Formular mit z.B mehreren Reitern und Unterelementen die Arbeit um einiges umständlicher gestalten.

Vor allem bei abhängigen Prüfungen und / oder größeren Formularen mit potenziell vielen Fehlermöglichkeiten wären hier wohl mehrere "Speicherversuche" notwendig, inkl. wiederholter Wechsel von Reitern, Öffnen von (ggf. verschachtelten) Listeneinträgen.

Viele Grüße

Michael

[nilsweber]

das klingt zumindest für den komplexen fall nachvollziehbar, aber ein wenig hinkt die erklärung schon; moderne frameworks wie spring mvc sind problemlos in der lage ein komplettes formular durchzuvalidieren und dann an beliebig zentraler stelle eine fehlerzusammenfassung anzuzeigen - es wäre dann ja in ordnung die felder auf den diversen reitern einzufärben.... aber eine regel on_save (linguistisch: "beim versuch des speicherns") zu nennen, die darin definierte validierung jedoch trotzdem "on_key_up" stattfinden zu lassen und nur ein sehr generisches hinweis-popup beim speichern anzuzeigen.... nicht sehr nutzerfreundlich.

trotzdem natürlich danke für die aufklärung.

[StefanSchulz]

Hi.

Die Regelkategorien ON_SAVE und ON_RELEASE dienen zur Einstufung und Verortung der Regel. Sie sagen etwas darüber aus, zu welchem Zeitpunkt die Regel valide sein muss, aber nicht, wann sie ausgeführt wird. Mag sein, dass die Namensgebung das Wissen um diesen Zielumstand voraussetzt und somit nicht eindeutig wirkt.

Der Hauptzweck der Regeln soll ja sein, dass ein Redakteur ein Formular fehlerfrei pflegen kann. Dafür muss er oder sie die Fehler möglichst orts- und zeitnah sehen. Eine Fehlersammlung beim Speichern oder bei Freigabe ist für die redaktionelle Arbeit eher unpraktisch und unproduktiv. Eine Fehlermeldung erst beim Speichern ist jedoch manchmal aus Effizienzgründen leider nicht zu umgehen. Dieser "generische Hinweis" wird in zukünftigen Versionen sicherlich erweitert, soweit dies möglich ist.

Beste Grüße

Stefan

[nilsweber]

Hallo Stefan,

wiegesagt, alles gut und irgendwo richtig, aber was Du denkst, was aus allgemein gesprochener redaktioneller Sicht meinetwegen sinnvoll erscheint und was wir hier für Befindlichkeiten aufzufangen haben, sind eben leider doch manchmal zwei verschiedene Dinge - da helfen auch mir leider kaum solche nachvollziehbaren und logischen Argumentationsketten, da ich diese wiederum für hier bei uns recht einflussreiche Redaktionschefseelen in eine andere Sprechweise übersetzen darf.

wiegesagt, *ich* kann das wohl nachvollziehen, aber *ich* muss hier auch nicht zufriedengestellt werden, denn *ich* bin letztlich kein Redakteur sondern Entwickler.

Danke

[StefanSchulz]

War ja auch eher als Erläuterung dazu gedacht, wieso es zu den Namen gekommen ist.