Benutzerdefinierte Regeln frieren das Layout ein

[Matthias Eckardt]

Guten Tag,

heute mal etwas, was einfach zu beschreiben ist.
Ich habe mit dem Serverregeleditor eine CustomRule erstellt. Da steht noch nichts drin, außer der leeren Methodenhülle, wie sie hier beschrieben ist:

http://wiki.nuclos.de/display/Konfiguration/Event+-+Benutzeraktion

Die wird kompiliert, kann einem Businessobjekt zugewiesen werden (per Ziehen), dann im Layouteditor einem Button per Befehlstyp „Regelbutton“ und Argumente „Regelname“(aus dem Drop Down Menü) auf einen Button gelegt werden.

Dann… öffnet man das Layout aus Nutzersicht, legt einen neuen Datensatz an, gibt irgendein Stückchen Text in eines der anderen Felder an, klickt auf den Button von gerade und…

Eigentlich sollte gar nichts passieren, weil außer dem Rumpf, den Nuclos ja selber sogar anlegt, nichts im Code getan wird. Uneigentlich jedoch wird das zugehörige Fenster dunkelgrau und die Sanduhr taucht auf. Und geht nicht mehr weg.
Man kann das Fenster schließen, bekommt gesagt, es handle sich um einen ungespeicherten Datensatz, und dann ist es auch zu.

Aber warum verhält sich Nuclos so, wenn ich eine benutzerdefinierte Regel per Button ausführe?

EDiT: Einen Nachschlag habe ich noch: wir haben jetzt gerade eine Breakpoint im Spring Framework gesetzt und uns mit dem Debugger auf die Lauer gelegt. Klickt man dann auf den Button, landet man… in den Klassen, die „InsertRule“ implementieren. Der Breakpoint in der Klasse mit der „CustomRule“ wird gar nicht angesteuert, aber trotz „Fortfahren“ im Debugger verbleibt das Fenster in dem unbrauchbaren Zustand.

[Ramin Goettlich]

Dann dürfte die InsertRule das Problem sein. Hintergrund: Wird eine CustomRule ausgeführt, wird der Datensatz im Anschluss gespeichert.

[Matthias Eckardt]

Guten Morgen,
und danke für die Antwort.
Was mich verwundert ist, dass der Debugger nicht in der CustomRule-Klasse zum Stehen kommt, bevor das passiert. Dass wir an fraglicher Stelle noch eine InsertRule haben, die nicht ganz perfekt arbeitet im Moment, kann ich bestätigen, aber ist es so gewollt, dass die InsertRule vor der CustomRule durchgeführt wird?

[Ramin Goettlich]

Ich bin mir nicht sicher.
Aber funktionierts denn, wenn die InsertRule deaktiviert ist? Dann ist die Sache doch klar.

[Matthias Eckardt]

Auf komplett unbedarften Nuclos-Instanzen klappt das mit dem Button. Was wir nicht verhindern können wie es scheint ist, dass dennoch beim Button-Klick gespeichert wird, auch wenn gar keine Insert-Regel vorhanden ist.
Das kann man leicht nachbauen: ein unspektakuläres BO, ein Button mit einer CustomRegel hinter der nur der nuclos-erzeugte Klassen-Rumpf liegt, dann einen neuen Datensatz anlegen, speichern, ihn ändern, den Button betätigen… und obwohl keine InsertRule definiert worden ist in dem Fall, wir der Datensatz dennoch gespeichert.

Das ist… ungünstig, wenn man aus der Datenbank Daten beziehen will, die nicht im aktuellen Datensatz liegen, diesen deswegen aber nicht speichern mag.
Und irgendwie glaube ich, dass der Endlosschleifen-Effekt beim Button-Klick auftreten könnte, wenn man normalerweise eine „kann nicht speichern weil Grund“ Meldung bekommen hätte. Die scheint aufgegessen zu werden.

[Nick Röder]

Mittlerweile gibt es im context ein Flag, dass gesetzt werden kann. Also in der CustomRule Regel kann

context.setUpdateAfterExecution(False)

gesetzt werden. Dann wird der DS nicht automatisch gespeichert.

[Ramin Goettlich]

Ob ein Datensatz gespeichert ist, hängt nicht davon ab, ob eine InsertRule definiert ist. Eine InsertRule ist lediglich etwas, das man optional zusätzlich beim Speichern eines (neuen) Datensatzes ausführen lassen kann.

Nach einer CustomRule wird der Datensatz generell gespeichert, denn wesentlicher Use Case einer CustomRule ist, den Datensatz zu verändern. Was nicht dem entgegensteht, in der CustomRule auch noch ganz andere Dinge machen. Möglicherweise wird er im Insert-Falle auch vorher gespeichert, da bin ich mir nicht sicher (siehe Frage in meinem Post weiter oben).

„Das ist… ungünstig, wenn man aus der Datenbank Daten beziehen will, die nicht im aktuellen Datensatz liegen, diesen deswegen aber nicht speichern mag.“ verstehe ich nicht.

Vielleicht würde es helfen, wenn Sie beschreiben, was Sie eigentlich erreichen möchten?

[Ramin Goettlich]

> „wenn man aus der Datenbank Daten beziehen will, die nicht im aktuellen Datensatz liegen“

Vielleicht helfen hier berechnete Attribute weiter?

[Nick Röder]

Mittlerweile gibt es im context ein Flag, dass gesetzt werden kann. Also in der CustomRule Regel kann

context.setUpdateAfterExecution(False)

gesetzt werden. Dann wird der DS nicht automatisch gespeichert.

[Matthias Eckardt]

@Elvis, wir haben nachgeschaut und die beschriebene Methode gefunden. Insert wird dennoch durchlaufen (auch wenn keine InsertRegel da ist), aber update kann man damit tatsächlich vermeiden. Das ist fast was wir gesucht haben 🙂

@nuclosian, im Moment versuchen wir herauszufinden, was alles damit eigentlich machbar ist. Ein Versuch war, in das gerade eben „aktive“ BO Daten aus anderen BOs einzutragen, die z.b. nicht direkt per Relation mit diesem aktiven verbunden sind. Wie das Herüberkopieren von Werten aus Datensätzen, die man an dieser Stelle unveränderlich gegenüber der Quelle einlagern möchte.

Aber jetzt ist da z.B. noch ein Pflichtfeld, das noch nicht ausgefüllt ist, wenn der Button gedrückt wird. Nachdem aber immer gespeichert wird, muss das spätestens hier schief gehen, nicht oder? Oder man hat den falschen Datensatz erhalten (oder will einen anderen haben), und die richtigen Werte zusammensammeln bevor man den Datensatz überhaupt speichert.
In den Fällen wäre „Button ohne Speicherpflicht“ eine dolle Sache.

[Nick Röder]

Sie können über einer ThreadVariable Regeln auch aus anderen Regeln deaktivieren.

Z.B. in der Insert Regel

//definition of thread local variable
public static final ThreadLocal ACTIVE = new ThreadLocal() {
protected Boolean initialValue() {return Boolean.TRUE;};
}

setzen und dann über

vollerRegelpfad.ACTIVE.set(Boolean.FALSE);

unbedingt über final-Block im try-Block wieder aktivieren

[Matthias Eckardt]

Vielen Dank, @Elivs,
wir haben es tatsächlich geschafft, mit dem von Ihnen bereitgestellten Code-Schnipsel insert und insert(after) zu umschiffen, wenn auf den Button geklickt wird… aber Speichern tut es trotzdem 🙂

Wenn es tatsächlich keine Möglichkeit gibt, die Aktionen hinter dem Button auszuführen ohne den im aktiven BO herumliegenden Datensatz zu speichern, dann werde ich unsere Versuche in der Richtung wohl oder übel einsellen müssen 🙁

[Frank Pavlic]

Hallo imunixx,
nicht einstellen, Daten in den aktuellen Datensatz per Button zu holen und Felder entsprechend setzen funktioniert, allerdings über eine Client-Extension. Dann hast Du alle Freiheiten. D.h. du implementierst einen Button-Typ und fügst diesen der Layout-Palette hinzu. Dann kannst Du diesen in deine Layouts einbauen.
Der Standard-Regelbutton speichert den Datensatz immer nach Ausführung der Regel.

Gruß
Frank

[Autor]

Beiträge