Im konkreten Fall wäre es das einfachste, die Gruppe zu verwenden. Aber es fehlen noch ein paar Randinformationen. Nehmen wir mal an, wir haben folgende Items:
Code: Alles auswählen
Group gWindows
String Window1 (gWindows)
String Window2 (gWindows)
String Window3 (gWindows)
Die Rule soll regelmäßig kontrollieren, ob der Status NULL ist und entsprechend reagieren:
Code: Alles auswählen
rule "check gWindows"
when
Member of gWindows changed
then
if(triggeringItem.state == NULL) triggeringItem.postUpdate("OFFLINE")
end
Fertig! Egal, welches Item WindowN seinen Status auf NULL ändert, es wird exakt dieses Item auf OFFLINE gesetzt.
Nun soll die Rule zusätzlich auf Zeit triggern. Damit steht dann kein triggeringItem zur Verfügung:
Code: Alles auswählen
rule "check gWindows"
when
Time cron "0 0 * * * ?" // zur vollen Stunde
Member of gWindows changed
then
if(triggeringItem !== null)
if(triggeringItem.state == NULL) triggeringItem.postUpdate("OFFLINE")
else
gWindows.members.forEach[m|
if(m.state == NULL) m.postUpdate("OFFLINE")
]
end
Fertig! Nun unterscheidet die Rule zwischen den zwei Triggern und setzt entweder konkret genau das Item, welches getriggert hat (unter der Voraussetzung, dass es NULL ist), oder, falls die Rule auf Zeit getriggert hat, durchläuft es die gesamte Gruppe und schaut sich jedes einzelne Item an.
da braucht es keine Prozeduren und keine Lambdas!
Da noch eine weitere Group als Trigger vorgesehen ist, könnte es theoretisch notwendig sein, noch eine weitere Unterscheidung zu treffen. Je nach Gruppenbeschaffenheit könnte man z.B. so:
Code: Alles auswählen
if(gWindows.members.filter[m|m.name == triggeringItem.name].size == 0)
prüfen, ob das TriggeringItem aus der ersten oder der zweiten Gruppe stammt.
Es mag Fälle geben, wo ein Lambda als Funktionsersatz tatsächlich die bessere Wahl ist, aber die Gruppen und die zugehörigen Funktionen sind extrem mächtig, der Code ist im Zweifel sehr schlank und (wenn man ein wenig über die Worte nachdenkt) sogar leicht verständlich.