Added registry of 'watchers', allowing functions to be executed when …

[ceball]

I've begun "Solve at param GUI toolkit level?" from holoviz/param#160 and have opened this PR to ask for feedback, not to merge. In particular, I am looking for more real world use cases to address. Anyone got any notebooks with examples where they have already done or want to do this kind of thing? (I'm working on a DateRange parameter and corresponding paramnb widget.)

Note that when you write code to link parameters the way I've done here, you currently have to know about both the widgets and the parameters :( E.g.

def update_days(widgets,**params):
    widgets['days'].max = speed[params['employee']]

What we discussed before was instead to update the parameter, and have that be reflected in the widget. So in this case it would mean setting the parameter's soft bounds, and seeing that updated in the slider. However, I'm not yet sure how that approach would work for parameters that don't have an equivalent of soft bounds (e.g. object selectors). But anyway, I guess the next step is to make it so that you only have to update the parameters.

[philippjfr]

The main examples I've run into is situations where I want to change the objects on a ObjectSelector and have the dropdown menu mirror that. One additional comment I have is that I think the watchers will be doing something similar to the various widget functions, which is to map parameter attributes to widget attributes. Worth investigating if initialization and updating of widget values can share code somehow.

[jbednar]

Updating soft_bounds would be correct for param.Number types, but for param.Selector types, updating what is returned by get_range (e.g. the list of available objects for an ObjectSelector) is the right thing to do. Eventually maybe the Widget class can register as a "watcher" for the underlying parameter, so that it updates when the parameter's bounds/range changes, without needing further domain-specific code at the Widget level.

[ceball]

Updating soft_bounds would be correct for param.Number types, but for param.Selector types, updating what is returned by get_range (e.g. the list of available objects for an ObjectSelector) is the right thing to do.

Hmm, I thought we discussed before that doing so might not be the right thing. I am probably mistaken...

In my notebook at https://github.com/ceball/paramnb/blob/1132e56df5037deb3972bd999d6cda64d1c9942e/doc/WidgetLinking.ipynb, I have a SomeManagement object s with all possible projects as objects of the project parameter. If in update_projects() I were to alter the project parameter's list of objects instead of altering the dropdown widget's options, then if I were to select Person Z for the employee I would not subsequently be able to type s.employee='Person X'; s.project='A' because A would have been removed from the project's list of objects.

[ceball]

The main examples I've run into is situations where I want to change the objects on a ObjectSelector and have the dropdown menu mirror that.

Do you mean like in the example notebook I added, or something different?

One additional comment I have is that I think the watchers will be doing something similar to the various widget functions, which is to map parameter attributes to widget attributes. Worth investigating if initialization and updating of widget values can share code somehow.

Thanks, I'll do that (once I've understood what the behavior to be).

[jbednar]

Updating soft_bounds would be correct for param.Number types, but for param.Selector types, updating what is returned by get_range (e.g. the list of available objects for an ObjectSelector) is the right thing to do.

Hmm, I thought we discussed before that doing so might not be the right thing. I am probably mistaken...

If I was present for that, I either didn't notice or don't remember. But I think you're right, and I guess we need the equivalent of soft_bounds for ranges, e.g. get_soft_range(). get_soft_range() would default to return self.get_range(), but could be overridden to return a subset of the full range. This wouldn't be used in checking validity, just when suggesting options as in a widget toolkit. Would that work?

[ceball]

I guess we need the equivalent of soft_bounds for ranges, e.g. get_soft_range(). get_soft_range() would default to return self.get_range(), but could be overridden to return a subset of the full range. This wouldn't be used in checking validity, just when suggesting options as in a widget toolkit.

I was thinking the same thing. But I was also wondering if all parameters that have bounds or range could share one name for 'soft bounds'/'soft range'? And then I was wondering if we shouldn't just have used the name 'range' everywhere rather than having bounds (e.g. for Number) and range (e.g. for ObjectSelector). Oh wait, we have a Range parameter with bounds...

[ceball]

Sorry, to be clear, I am actually suggesting we should have one name for the 'soft bounds'/'soft range'/'suggested range'/'values hint' concept, for all parameters with bounds/range. Or is there somewhere that wouldn't make sense?

I'm not suggesting we do the same for the hard bounds/range.

[ceball]

Oops, sorry, to be even more clear! Let's not discuss the name(s) of 'soft bounds' right now. It's not relevant to this PR, and I didn't think much about it anyway.

[ceball]

Eventually maybe the Widget class can register as a "watcher" for the underlying parameter, so that it updates when the parameter's bounds/range changes, without needing further domain-specific code at the Widget level.

Yes, that's mentioned in holoviz/param#160, but there are many possible problems (confusion about what cascade of things might happen when you set a parameter? performance impact on getting a parameter value? etc) that I feel we have to be strongly motivated to do it, with clear real world use cases.