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.
