Gibt es eigentlich einen wichtigen Unterschied zwischen einem Macro und einer Funktion in der 99_MyUtils? Beide Male schreibe ich den gleichen Code zwsichen { und }
Laufzeit? Performance? Speicher? Irgendetwas anderes?
Ich weiß nicht was du mit Macro meinst (in dem Fall). Je nach Fall dient eines oder das andere der besseren Übersicht oder Wartbarkeit.
define myMacro notify myMacro {}
dann aufrufen mit
trigger myMacro
In dem "Macro" Fall wird der Text vor jeder Ausfuehrung geparst, sonst nicht, d.h die Ausfuehrung dauert laenger. Der Zeitunterschied sollte im Normalfall zu vernachlaessigen sein, konkrete Zahlen habe ich aber keine.
Falls ein Problem mit PERL WARNING gemeldet wird, dann ist das Lokalisieren im Macro-Fall komplizierter, weil stacktrace keinen Funktionsnamen anzeigen kann.
Die Editiermoeglichkeiten bei Macro sind eingeschraenkter / komplizierter wg. ;; und \, dafuer ist das Nachladen von ausgelagerten Funktionen etwas aufwendiger.
Als grobe Richtlinie: ich wuerde alles, was mehr als 5 Zeilen Code ist, in Funktionen implementieren.
Was hätte es eigentlich für Auswirkungen, wenn ich eine sub in ein notify schreibe?
Beispiel für die Raw definition:
defmod myWebTitle notify global:INITIALIZED {\
sub WebTitle {\
my $title;;\
\
if($FW_detail){\
$title = AttrVal($FW_detail, "alias", $FW_detail);;\
}\
elsif($FW_room){\
if($FW_room eq "all"){\
$title = "Everything";;\
}\
else{\
$title = "$FW_room";;\
}\
}\
elsif(defined $FW_webArgs{cmd}){\
if($FW_webArgs{cmd} =~ m/style edit (.*)/s){\
$title = "Edit: $1";;\
}\
elsif($FW_webArgs{cmd} =~ m/style save (.*)/s){\
$title = "Saved: $1";;\
}\
elsif($FW_webArgs{cmd} =~ m/style list.*/s){\
$title = "Edit files";;\
}\
elsif($FW_webArgs{cmd} =~ m/style eventMonitor.*/s){\
$title = "Event monitor";;\
}\
elsif($FW_webArgs{cmd} =~ m/style select.*/s){\
$title = "Select style";;\
}\
else{\
$title = $FW_webArgs{cmd};;\
}\
}\
elsif(defined $FW_webArgs{file}){\
$title = "Log: $FW_webArgs{file}";;\
}\
elsif\
(%FW_webArgs and\
((keys %FW_webArgs)[0] =~ m#dashboard/(.*)#s)\
){\
$title = $1;;\
}\
else{\
$title = AttrVal("global", "title", "Home, Sweet Home");;\
}\
return $title;;\
}\
}
Vorteil: es lässt sich einfach über Raw definition teilen
Nachteil: es wird erst bei einem Neustart geladen
Zitat von: igami am 04 Februar 2018, 08:08:35
Was hätte es eigentlich für Auswirkungen, wenn ich eine sub in ein notify schreibe?
<...>
Vorteil: es lässt sich einfach über Raw definition teilen
Nachteil: es wird erst bei einem Neustart geladen
*hust*
Warum? .... Weil man es kann! ::)
Der Vorteil "Raw-Definition" ist m.E. keiner! Sauberer Quelltext aus einer 99_MyUtils.pm lässt sich genauso leicht teilen (Copy-Paste über den Editor) und ist isoliert sogar noch besser zu lesen, als der Raw-Kram!
Der angeführte Nachteil wäre aber auch keiner, denn du könntest dein notify auch so abändern, dass es zusätzlich bei einer Änderung seiner Selbst getriggert wird, bzw. es "von Hand" triggern. Eine sub in einem 99er-Modul wird übrigens auch erst beim Neustart oder einem erzwungenen reload geladen (ja, der reload erfolgt bei Änderung über FHEMWEB-Editor automatisch)
Das mit der quasi "Macro"-Funktionalität des notify hat sich mir bisher noch nicht wirklich erschlossen. Ich würde demgegenüber immer (!) eine sub in einer 99_whateverUtils.pm vorziehen.
... das war, was mir dazu einfiel!
Schönen Sonntag noch!
gb#
Zitat von: Benni am 04 Februar 2018, 09:16:25
*hust*
Warum? .... Weil man es kann! ::)
Weil es dann wirklich einfach copy/paste. Anstelle also zu schreiben
1. Füge folgenden Code in deine myUtils ein
2. setze das Attribut im FHEMWEB auf XX
Schreibt man einfach die Raw definition
defmond sub_notify notify { ... }
trigger sub_notify
attr FHEMWEB title myWebTitle
Aber über Sinn und Unsinn lässt sich ja bekanntlich streiten :)