-
-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow a param.Selector with no objects to be turned into an AutocompleteInput widget #2966
Conversation
Presumably an AutocompleteInput widget returns only strings, but a Selector with no items won't have any such restriction. Will this fix also apply to a ClassSelector with a |
Codecov Report
@@ Coverage Diff @@
## master #2966 +/- ##
==========================================
+ Coverage 83.46% 83.47% +0.01%
==========================================
Files 190 190
Lines 25206 25217 +11
==========================================
+ Hits 21038 21050 +12
+ Misses 4168 4167 -1
Continue to review full report at Codecov.
|
It is true that a Selector doesn't put any constraint on the type of data it contains (I thought Isn't a |
But won't that database query always return the same type of object? In that case it should be a ClassSelector, which is meant for a collection of items in the same class, not a Selector, which is meant for a specific set of concrete items, probably but not necessarily sharing the same class. Where it matters is for downstream code -- can it assume that the result is of a particular class or shares a certain API? If so, that should be declared rather than assumed.
At the Param level, a ClassSelector with |
Yes. But I'm not sure I follow your point, how can I declare a
|
Ah, good point. It looks like ClassSelector won't actually use its objects list, invalidating my point. And thus ClassSelector doesn't need a Ok, I'm back to the original issue that using an AutocompleteInput with Selector will always generate a string result, and there is I guess currently no way to declare that constraint in a way that downstream code can rely on. So we'll have the situation that people will instantiate a Selector, happily use it with AutocompleteInput, assume that the result will always be a string, and yet Param won't actually enforce that it is a string, causing problems for anyone who uses that code in a context not driven by a Panel AutocompleteInput. To prevent such problems, it looks like either the |
Ok I understand better why I was confused by your suggestions now! It'd be indeed useful to have a Parameter that has a list of possible objects which are of one or more declared types. |
I've merged |
Minor fix to allow a
Selector
Parameter that is defined with no objects from the beginning to be turned into anAutocompleteInput
widget.