Übergabe von Zeichenketten mit Leerzeichen an get-Befehle

Begonnen von tupol, 16 April 2016, 10:35:36

Vorheriges Thema - Nächstes Thema

justme1968

na das war schnell :)

hier ist der zweite teil. damit kann ein modul in Initialize $hash->{parseCmds} auf 1 setzen, dann wird DefFn, SetFn und GetFn nicht mehr mit dem string bzw. dem gesplittete string aufgerufen sondern mit array ref und hash ref aus dem parseParams ergebnis. für module die parseCmds nicht gesetzt haben bleibt alles beim alten.

um das so einfach wie möglich einzubauen kann man parseParams jetzt entweder mit dem string (für DefFn) und mit einer array ref (für SetFn und GetFn) aufrufen.

wo sollte man die routine, deren automatisch und manuelle verwendung sowie die erlaubte syntax dokumentieren?


wie im anderen thread schon geschrieben könnte man den aufruf auch zusammen mit dem perlSyntaxCheck verwenden und erst alles durch parseParams schicken und dann jeden {...} teil einzeln durch perlSyntaxCheck. offen wäre ob man das zentral in perlSyntaxCheck einbaut oder  ob jeder aufrufen von perlSyntaxCheck dafür selber zuständig ist.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Habe deinen Patch eingecheckt, nur den $hash-Eintrag von parseCmds nach parseParams geaendert.

Zitatkönnte man den aufruf auch zusammen mit dem perlSyntaxCheck verwenden und erst alles durch parseParams schicken und dann jeden {...} teil einzeln durch perlSyntaxCheck.
Verstehe ich nicht:
fhem> { use Data::Dumper;; Dumper parseParams("{ a;;b };;c;;{ d;;e }") }
$VAR1 = [
          '{ a;b };c;{ d;e }'
        ];
$VAR2 = {};


parseParams zerlegt mir doch die Befehlszeile nicht in Einzelteile. Und wenn nicht: wobei hilft sie mir?

justme1968

dazu muss man natürlich dann an ; splitten. nicht am leerzeichen. z.b. in dem man das trennzeichen optional mit übergibt:{ use Data::Dumper;; Dumper parseParams("{ a;;b };;c;;{ d;;e }", ';;') }
$VAR1 = [
          '{ a;b }',
          'c',
          '{ d;e }'
        ];
$VAR2 = {};


hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Sehe ich falsch, oder muss das noch implementiert werden?
Dann muesste ich auch die Deklaration (sub parseParams($)) anpassen.

justme1968

#19
der patch der dran hängt macht genau das. :)

ps: man muss dann in perlSyntaxCheck auf ^\s?{.*}\s?$ prüfen da die leerzeichen nicht mehr getrimmt werden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Sorry, war nicht aufmerksam.
Hab dein Patch eingespielt, parseParams ans Ende von fhem.pl verschoben, und sie in perlSyntaxCheck aufgerufen.

tupol

#21
Vielen Dank für die schnelle Reaktion. Finde ich echt super, wie schnell das Problem gelöst wurde.

@justme1968
Also ich habe das jetzt folgendermaßen verbaut:
my ($a, $h) = parseParams( join (" ", @val) );
@val = @$a;


Wäre es vielleicht auch möglich, das ganze so zu realisieren, das bereits ein
@val = parseParams @val;
zum Erfolg führt?

justme1968

du kannst statt dem string inzwischen (ab morgen) auch eine ref auf das gesplittete array übergeben. d.h. das join kann entfallen:my ($a, $h) = parseParams( \@val );

die zuweisung zum dereferenzieren der rückgabe könnte man vielleicht auch noch weg bekommen aber eigentlich ist das doch ein sonderfall da es effizienter ist das array nicht noch mal zu kopieren.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tupol

Danke.
Die 2. Zeile ist aber eher Faulheit, da ich so den Code nicht ändern muss und Faulheit ist bei mir beim Coden eher kein Sonderfall.  ;D

tupol

#24
So mal schnell gegrübelt. Die Sache mit dem = ist ja eine Superidee. Ich habe das bisher mit "say:" gelöst.

Aber könnte es nicht sein, dass Module die Parameter in einer bestimmten Reihenfolge erwarten und der Hash, dann alles durcheinanderbringt? Vielleicht in den ersten @a alles packen und hinter %h noch den aktuellen @a packen?

justme1968

das = ist ja gerade dazu da um jeden parameter zu benennen und nicht mehr von der reihenfolge abhängig zu sein.

zur zeit überschreibt ein weiterer parameter mit gleichem namen auch den zuvor gesetzten.

den fall das es trotzdem noch von der reihenfolge abhängt hatte ich bis jetzt noch nicht.

die frage währe jetzt ob nur die reihenfolge der parameter mit gleichem namen wichtig ist oder auch dir reihenfolge von parametern mit unterschiedlichem namen und wie ein modul das dann der parse routine bekannt gibt.

für ersteres könnte man statt dem wert ein array aus werten in den hash stecken. für die reihenfolge unterschiedlicher parameter untereinander würde ich sagen das ist schon sehr speziell. dafür sollte das modul eine eigene parse routine mitbringen.

ich denke es ist wichtiger die 90% der standard fälle gut abzudecken als viele einzelne unterschiedliche sonderfälle einzubauen und und es dann schwerällig und unübersichtlich zu machen.

eine dritten rückgabe ref mit einem array das auch die reihenfolge der benannten parameter beibehält wäre vielleicht eine option. wer es nicht braucht gibt es einfach nicht mit an.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

ich habe noch mal geschaut. das automatische unterscheiden von my ($a, $h) = parseParams( \@val );und@val = parseParams( \@val );um automatisch das richtige zurück zu geben geht leider nicht da in beides als list context erkannt wird.

man könnte es zwar so schreiben um die zweite zeile einzuspaaren:@val = @{(parseParams( \@val ))[0]};aber ich glaube das ist nicht wirklich übersichtlicher als zwei zeilen zu spendieren :)


zur reihenfolge der benannten parameter: sollten wir noch eine möglichkeit finden das in die allgemeine routine einzubauen oder ist das zu speziell?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

Hi André,


ich habe gerade festgestellt, dass das Array @a bei Nutzung des modify-Befehls an der zweiten Stelle nicht mehr den Modulnamen hat, sondern direkt den ersten Parameter. Das ist natürlich unschön, wenn man z.B. über FHEMWEB eine Änderung durchführt und die Parameter plötzlich an anderer Stelle sind. Ich habe auch keine Möglichkeit gesehen zu erkennen, ob gerade define oder modify verwendet wird. Ich wollte nur ungern fix auf den Modulnamen an der zweiten Position prüfen, da man ansonsten den 1. Parameter nicht mehr so benennen kann wie das Modul heißt.


Ich schlage also vor, dass auch bei einem modify das Array entsprechend gleich befüllt würd.


Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatIch habe auch keine Möglichkeit gesehen zu erkennen, ob gerade define oder modify verwendet wird.
By modify existiert ein $hash->{OLDDEF}

justme1968

das ist keine absicht und vermutlich ein copy&paste fehler zwischen define und modify. der TYPE muss vermutlich einfach nur passend vorangestellt werden.

ich schaue es mir an und mache einen patchvorschlag.

ich habe aber gerade nur eingeschränkt zugrif auf einen rechner und es könnte bis dienstag oder mittwoch dauern.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968