Funktioniert isValid zusammen mit Rules?

alexanderan · ‎07-09-2013

Hallo zusammen,

in FS 4.2 hatte man die Möglichkeit Eingabewerte über die isValid()-Methode des EditorValue zu prüfen. War der Eingabewert ein Pflichtfeld (allowsEmpty=no) und der Wert war nicht gefüllt, so lieferte die Methode isValid() den Rückgabewert false.

Mit FS 5.0 wurden die Rules eingeführt, mit denen man die Pflichtfelder dynamischer gestalten kann (z.B. unter Berücksichtigung des Flags für "Übersetzt").

Werden die Rules auch beim Aufruf der Methode isValid() geprüft?

Falls nicht, kann man die Regel auch programmatisch ausführen?

Das würde mich auch bei einer Positiven Antwort auf die erste Frage interessieren 🙂

Hintergrund meiner Frage ist der folgende:

Wir haben in einem Absatztemplate eine FS_LIST Komponente, mit welcher Absätze der eigenen Seite ausgewählt werden können. Diese Eingabekomponente darf nicht leer sein. Dies Prüfen wir mit einer Regel (ON_SAVE).

Nun kann ein Redakteur allerdings den gewählten Absatz nach dem Speichern löschen. Somit ist die Regel eigentlich verletzt. Dennoch hat er die Möglichkeit diese Seite freizugeben. Die Regel wird bei der Freigabe nicht geprüft.

Natürlich könnten wir die Regel noch einmal duplizieren und zusätzlich ON_RELEASE ausführen. Das würde aber den ohnehin schon gut gefüllten Rules-Bereich noch zusätzlich aufblähen. Zudem würden wir gerne dem Benutzer schon beim Starten unseres Freigabe-Laufes darauf hinweisen.

Viele Grüße,

Andreas Alexander

mbergmann · ‎07-09-2013

Zur zweiten Frage:

Programmatisch sollte das über einen ValidationAgent geprüft werden:

de.espirit.firstspirit.agency.ValidationAgent (DEV-API).

Achtung, hier erfolgt meines Wissens keine automatische Rekusion z.B. von Seiten in Absätze.

Viele Grüße

Michael Bergmann

alexanderan · ‎07-12-2013

Vielen Dank für den Hinweis.

Ich habe auch schon die ersten Beispiele mit dem ValidationAgent ausprobiert. Dabei ist mir das folgende aufgefallen.

Der ValidationAgent hat zwei Public Methoden:

MultiFormValidationReport validate(IDProvider element, ValidationAgent.ValidationScope scope)

Mittels dieser Methode kann man die Regeln direkt auf einem IDProvider validieren. Also auf einer Page oder einer Section. Wie Herr Bergmann im vorherigen Post schon erläutert hat, werden die Regeln nicht rekursiv geprüft.

MultiFormValidationReport validate(FormData formData, Iterable<Language> languages, ValidationAgent.ValidationScope scope)

Mittels der zweiten Methode können Regeln selektiv auf für ein konkretes FormData Objekt und eine konkrete Sprachen geprüft werden.

Bei der ersten Methode haben meine ersten Versuche gezeigt, dass die Ausführung Regeln bei Übergabe einer Page oder einer Seite leider nicht rekursiv auf die Inhalte der Eingabekomponenten (wie bspw. FS_LIST) angewendet werden.

Wir haben in unseren Projekten diverse Verwendungen von FS_LIST Komponenten in denen Absätze verwendet werden, die wiederum Regeln beinhalten. Bei Fehlerhaften Eingaben in diesen Absätzen war das Ergebnis der Prüfung auf der Section trotzdem erfolgreich.

Also habe ich die zweite Methode ausprobiert. Hier hat der Entwickler es ja selbst in der Hand die Inhalte einer FS_LIST rekursiv zu validieren. Das erste Beispiel funktionierte hier auch tadellos. Als ich allerdings auf etwas kompliziertere Regeln gestoßen bin musste ich feststellen, dass der Agent bei diesem Methoden-Aufruf nicht mehr auf #global zugreifen kann.

Das wird unter anderem benötigt, um eine Regel bei Absätzen, die nicht in die Generierung inkludiert sind auszuschalten. Dort bekommt man leider nur eine Meldung der folgenden Art:

DEBUG 12.07.2013 13:05:57.735 (de.espirit.firstspirit.forms.rules.Rule): Failed evaluating condition!

FSVersion=5.0.318.57504#3400;JDK=1.6.0_30 32bit Sun Microsystems Inc.;OS=Windows XP 5.1 x86;Date=12.07.2013 13:05:57

de.espirit.firstspirit.forms.rules.FactBase$NoSuchFactException: There is no fact 'TRANSLATED' for item '#global'!

at de.espirit.firstspirit.store.access.GlobalPropertyFacts.getFact(GlobalPropertyFacts.java:104)

at de.espirit.firstspirit.store.access.FormAccessingFactBase.getFact(FormAccessingFactBase.java:63)

at de.espirit.firstspirit.forms.rules.Property.provide(Property.java:56)

at de.espirit.firstspirit.forms.rules.Property.holdsOn(Property.java:66)

at de.espirit.firstspirit.forms.rules.Rule.isSatisfied(Rule.java:245)

at de.espirit.firstspirit.forms.rules.Rule.fire(Rule.java:205)

at de.espirit.firstspirit.forms.rules.RuleEngine.doProcess(RuleEngine.java:215)

at de.espirit.firstspirit.forms.rules.RuleEngine.reset(RuleEngine.java:124)

at de.espirit.firstspirit.forms.rules.Rules.validate(Rules.java:261)

at de.espirit.firstspirit.forms.rules.Rules.validate(Rules.java:198)

at de.espirit.firstspirit.forms.rules.Rules.validate(Rules.java:176)

at de.espirit.firstspirit.forms.rules.Rules.validate(Rules.java:157)

...

Ein weiterer Versuch der Regelprüfung auf MetaDaten hatte leider auch keinen Erfolg. Dazu habe ich ein Ticket beim Helpdesk eingestellt. Sobald ich hier eine Rückmeldung erhalte, werde ich diesen Beitrag aktualisieren.

Den einzigen (und vermutlich auch vom Entwickler des ValidationAgent vorgesehenen) Weg, den ich sehe ist die Verwendung der ersten Methodensignatur für alle Pages und Sections. Und den anschließenden rekursiven Aufruf für alle FS_LIST-Komponenten der Seite bzw. des Absatzes.

In den Templates der FS_LIST Absatzvorlagen können dann in der Tat keine Aufrufe von #global oder ähnlichen auf die Seite oder den Absatz bezogenen Daten verwendet werden.

MichaelaReydt · ‎07-31-2013

Hallo,

Sie schrieben, Sie haben ein Ticket beim Helpdesk erstellt. Könnten Sie die entsprechende ID des Tickets ebenfalls hier posten, um potentiell auch anderen Usern eine Nachverfolgung des Tickets zu ermöglichen?

Vielen Dank und viele Grüße

Michaela Pahl