Problem when Item has the same name as a class Item method

[onkelandy]

Quite some problems might occur if an item is named the same as a method in the item class, such as path, id, age, etc.

I suggest two approaches: a) replace all method calls in core, e.g. in smartplugin by the property. For example instead of item.path() -> item.property.path b) extend the item check functionality that tests for item names that might clash with python to also log a warning if an item is called the same as an item method

Furthermore, I think in https://smarthomeng.github.io/dev_doc/lib/item_class_item.html the "Available only in SmartHomeNG v1.6, not in versions above" for path() is wrong?

[msinn]

a) replace all method calls in core, e.g. in smartplugin by the property. For example instead of item.path() -> item.property.path

Nope, that would only fix the issue, if the class methods in question would be removed and that would be a massive breaking change.

b) extend the item check functionality that tests for item names that might clash with python to also log a warning if an item is called the same as an item method

Could be done, but I haven't seen any problem reports concerning this in the forum or issues up to now.

Furthermore, I think in https://smarthomeng.github.io/dev_doc/lib/item_class_item.html the "Available only in SmartHomeNG v1.6, not in versions above" for path() is wrong?

Yup

[onkelandy]

Ad a) Ja, stimmt schon, andererseits würde ein Anpassen des Core Codes zumindest die Gefahr drastisch verringern, dass da was Unerwartetes passiert. ad b) Kann dir gerne einen Forumbeitrag erstellen ;) Bin selbst erst grad bei der Kombination von smartvisu Plugin WebIF und lms Plugin auf den Fehler gestoßen..

Jan 30 21:37:48 ERROR    cherrypy.error.546951669792 [30/Jan/2024:21:37:48] HTTP 
Traceback (most recent call last):
  File "/home/smarthome/.local/lib/python3.9/site-packages/cherrypy/_cprequest.py", line 638, in respond
    self._do_respond(path_info)
  File "/home/smarthome/.local/lib/python3.9/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond
    response.body = self.handler()
  File "/home/smarthome/.local/lib/python3.9/site-packages/cherrypy/lib/encoding.py", line 223, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/home/smarthome/.local/lib/python3.9/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/usr/local/smarthome/plugins/smartvisu/webif/__init__.py", line 144, in get_data_html
    item_config = self.plugin.get_item_config(item)
  File "/usr/local/smarthome/lib/model/smartplugin.py", line 280, in get_item_config
    return self._plg_item_dict[item_path].get('config_data')
KeyError: 'file:///music/Discographies/Therapy/Therapy%20-%201994%20-%20Troublegum/01.%20Therapy%20-%20Knives.mp3'

Es wurde hier also der Wert des Unteritems namens path ausgewertet anstatt dass der Itempfad zurückgegeben wurde. Werde jetzt mal das Pluginstruct anpassen oder wie sollen wir hier vorgehen? Ist halt auch ein breaking change, aber das Plugin ist noch recht frisch und vermutlich nicht sonderlich weit verbreitet...

[Morg42]

Das Problem rührt natürlich im Kern daher, dass Unteritems als Objektvariablen im Item angelegt werden (was nicht selbstverständlich und nicht streng notwendig ist). Während das tatsächlich Probleme machen kann, halte ich das nicht für sinnvoll verzichtbar; als Architekturfeature müsste der gesamte Core und ein Großteil der Plugins neu geschrieben werden.

Variante b) würde das Problem lösen zu Lasten der User, die ihre Items umbenennen müssten. Lösen allerdings nur vorläufig; wenn lib.item.item irgendwann neue Methoden bekommt (siehe add_item/remove_item/..., auch wenn das schlechte Beispiele sind ;) ), passierte das wieder von Neuem.

Also entweder a) damit leben und Plugins (Core?) so anpassen, dass statt item.id() -> item.path() -> item.property.path verwendet wird und das gelegentliche Problem hinnehmen, b) beim Lesen der Items prüfen, ob der Name des Sub-Items als Methode/Eigenschaft des Items vorhanden ist und ba) das Unteritem nicht anlegen bb) das Unteritem nicht als Objekteigenschaft einbinden (schlecht, weil inkonsistent)

Ich sehe das nicht als kurzfristig dringendes Problem und tendiere daher zu b) bzw. bb)

[msinn]

Ich hätte noch eine Option, eine Variante zu ba): Eine Warning loggen.

Bisher gibt es in lib/config.py die Methoden remove_reserved() (verhindert Itemnamen, die einem shng Keyword entsprechen) und remove_keyword (verhindert Item Namen, die einem Python keyword entsprechen).

Als shng Keywords sind dort bisher nur ['set', 'get', 'property'] definiert.

Man könnte eine Methode warn_reserved() ergänzen, die zwar die Anlage des Items zulässt, aber einen Log Eintrag erstellt. Die offene Frage dabei ist, wie man die Liste der entsprechenden Keywords am einfachsten erstellt. Ein Ansatz könnte sein, die Liste z.B. mit dir(Item) zu erstellen. Damit würde sie immer aktuell sein.

Als Nachteil ergäbe sich, dass sich die Startzeit von shng erhöht.

[Morg42]

Fixed by #628