Renaming Action Callbacks

I have run into a situation where I renamed some action callbacks and this is causing errors for users because the old callback name is still being targeted after they install the updated plugin version. Users can clear the error by opening up the suspect Action and pointing to the new item. Since self.actionsTypeDict is built through an introspection of the Actions.xml file in the plugin package, I can't use that to update the Action set. Effectively, what I need to do is something like this:

Code: Select all

def updateIndigoActionsDict(self):

    if 'oldName' in self.actionsTypeDict.keys():
        self.actionsTypeDict['newName'] = self.actionsTypeDict['oldName']
        del self.actionsTypeDict['oldName']

    return self.actionsTypeDict


Alternatively, is there an elegant way to update these references when the new version of the plugin is installed? Maybe the solution is to not rename Action callbacks.

Just doing some catchup on the forums and saw this. One way you could get around this would be to allow the defunct callback but hide it so it cannot be selected again and each time it is fired you could pop a big message in the event window to change it. I run into this when I'm sunsetting an old device, except what I do is hide all the fields in lieu of a label that requests they switch to the new type and then the device is renamed with (LEGACY) or something behind it so it's easily identified on the list.

Just doing some catchup on the forums and saw this. One way you could get around this would be to allow the defunct callback but hide it so it cannot be selected again and each time it is fired you could pop a big message in the event window to change it. I run into this when I'm sunsetting an old device, except what I do is hide all the fields in lieu of a label that requests they switch to the new type and then the device is renamed with (LEGACY) or something behind it so it's easily identified on the list.

I think this is what I'll do. I just wondered whether there was a way to update the server like we do with prop or state changes.

Thanks for that.

[jay (support)]

Sorry, somehow I missed this post. I don't believe there's really an elegant way of replacing it. Matt can jump in here if he can think of anything.

Maybe the solution is to not rename Action callbacks.

+1

But in all seriousness, why the reason for renaming the actions? You can always edit the UI name of the action so the user sees something different, but the key can stay the same. I freely admit that I have some action type IDs out there (and device type IDs as well) that don't really reflect what they do because their purpose has mutated over time.

[matt (support)]

Yeah, no good way to handle this currently. We did recently add a way (hard coded into Indigo, so not ideal) to mutate plugin IDs but there isn't a way currently to mutate/migrate callbacks or other type IDs. We'll probably look more into that at some point though.

But in all seriousness, why the reason for renaming the actions? You can always edit the UI name of the action so the user sees something different, but the key can stay the same. I freely admit that I have some action type IDs out there (and device type IDs as well) that don't really reflect what they do because their purpose has mutated over time.

This "need" is totally in OCD territory. I decided that I would rename all my methods using PEP 8 compliant names so that it would be easy to tell them apart from the native Indigo methods.

Code: Select all

# Indigo
    def closedPrefsConfigUi(self, valuesDict, userCancelled):

# Me
    def adjust_refresh_time(self, valuesDict):


I then put all the Indigo methods at the top of the class and mine after those. Makes for a nice clean IDE experience. Like I said. OCD.

I then put all the Indigo methods at the top of the class and mine after those. Makes for a nice clean IDE experience. Like I said. OCD.

I'm the same way, I try to use PEP 8 compliant naming everywhere, even to the point that I redirect the plugin native calls to a library (I do this for a number of reasons, not just this) so I redirect as such:

Code: Select all

   ###
   def deviceStartComm (self, dev):
      try:
         device_library_object_i_created_somewhere_in_the_plugin.device_start_com (dev)
         
      except Exception as e:
         ...

Nice to know that I'm not the only one.

Nice to know that I'm not the only one.

Nope, you aren't!

I try to be as complaint with both the PEP docs as much as possible throughout all my code, including the headers and various attributes for the header. I've become quite accustomed to it as a way to keep versioning controlled on a module-by-module basis. I really utilize those parameters in my code too, and go to town on them in HKB 2.0, by using them as variables in my lists and things, for example:

Code: Select all

retList.append((dev.id, my_library_function.__doc__))


I try too, but there are a few places that I don't agree with PEP 8, and do my own thing. For example:

Code: Select all

# I find this to be much more readable:
cloud_cover        = self.nested_lookup(observation, keys=('cloudCover',))
forecast_time      = self.nested_lookup(observation, keys=('time',))
humidity           = self.nested_lookup(observation, keys=('humidity',))
icon               = self.nested_lookup(observation, keys=('icon',))
ozone              = self.nested_lookup(observation, keys=('ozone',))
precip_intensity   = self.nested_lookup(observation, keys=('precipIntensity',))
precip_probability = self.nested_lookup(observation, keys=('precipProbability',))
precip_type        = self.nested_lookup(observation, keys=('precipType',))
pressure           = self.nested_lookup(observation, keys=('pressure',))
summary            = self.nested_lookup(observation, keys=('summary',))
temperature        = self.nested_lookup(observation, keys=('temperature',))
uv_index           = self.nested_lookup(observation, keys=('uvIndex',))
visibility         = self.nested_lookup(observation, keys=('visibility',))
wind_bearing       = self.nested_lookup(observation, keys=('windBearing',))
wind_gust          = self.nested_lookup(observation, keys=('windGust',))
wind_speed         = self.nested_lookup(observation, keys=('windSpeed',))

# Than this:
cloud_cover = self.nested_lookup(observation, keys=('cloudCover',))
forecast_time = self.nested_lookup(observation, keys=('time',))
humidity = self.nested_lookup(observation, keys=('humidity',))
icon = self.nested_lookup(observation, keys=('icon',))
ozone = self.nested_lookup(observation, keys=('ozone',))
precip_intensity = self.nested_lookup(observation, keys=('precipIntensity',))
precip_probability = self.nested_lookup(observation, keys=('precipProbability',))
precip_type = self.nested_lookup(observation, keys=('precipType',))
pressure = self.nested_lookup(observation, keys=('pressure',))
summary = self.nested_lookup(observation, keys=('summary',))
temperature = self.nested_lookup(observation, keys=('temperature',))
uv_index = self.nested_lookup(observation, keys=('uvIndex',))
visibility = self.nested_lookup(observation, keys=('visibility',))
wind_bearing = self.nested_lookup(observation, keys=('windBearing',))
wind_gust = self.nested_lookup(observation, keys=('windGust',))
wind_speed = self.nested_lookup(observation, keys=('windSpeed',))


LOL, I do that as well when I have long lists, a hold over writing PHP and VB. PEP be damned, I want readability when I have big lists.

[jay (support)]

I decided that I would rename all my methods using PEP 8 compliant names so that it would be easy to tell them apart from the native Indigo methods.

[SNIP]

I then put all the Indigo methods at the top of the class and mine after those. Makes for a nice clean IDE experience. Like I said. OCD.

So, make it painful for users just to satisfy your OCD?

Yeah, in hindsight, we should have been more aware of PEP8 back in 2010 (rather than being influenced by Objective-C) when we were designing the plugin API. Oh, well, you live and learn!

So, make it painful for users just to satisfy your OCD?

If I must I will, they don't have to wade through thousands of lines of code (sometimes tens of thousands), they can cope .

So, make it painful for users just to satisfy your OCD?

If I do it properly, then they shouldn't ever know the difference.

Yeah, in hindsight, we should have been more aware of PEP8 back in 2010 (rather than being influenced by Objective-C) when we were designing the plugin API. Oh, well, you live and learn!

Well, frick, am I the only one that doesn't like how PEP8 looks and reads? Though, in the end, with the usual "team" developing our plugins (read: ourselves), as long as it is easily readable and recognizable by you, it is all good.