You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A requirement that is coming up more and more often is that we wanted cascading choices e.g. a dropdown choice should filter the possibilities of a following autocomplete field of the same form.
This is currently impossible and I'm not even sure how we would implement such a feature. On the autocomplete request side it's easy, we would add a optional_params kwarg or something and stick in the optional filter params there, this is also a good place to add the request (#42) others have requested in the past but we refrained because it was a breaking-change.
On the consumer side, it's a bit more complicated. Ideally we'd want the user to allow extra params to be passed. These can come from the form dynamically or statically from some variable. In the case of forms, ideally we could rename the form-field so that the same autocomplete class and get_items implementation can be re-used in different forms that use different field names for the same type of data.
(Note that for the static case, there is a meta-programming workaround: generate as many autocomplete classes are there are possibilities. This is kind of hacky and won't work for user-picked options)
The text was updated successfully, but these errors were encountered:
A requirement that is coming up more and more often is that we wanted cascading choices e.g. a dropdown choice should filter the possibilities of a following autocomplete field of the same form.
This is currently impossible and I'm not even sure how we would implement such a feature. On the autocomplete request side it's easy, we would add a
optional_params
kwarg or something and stick in the optional filter params there, this is also a good place to add the request (#42) others have requested in the past but we refrained because it was a breaking-change.On the consumer side, it's a bit more complicated. Ideally we'd want the user to allow extra params to be passed. These can come from the form dynamically or statically from some variable. In the case of forms, ideally we could rename the form-field so that the same autocomplete class and get_items implementation can be re-used in different forms that use different field names for the same type of data.
(Note that for the static case, there is a meta-programming workaround: generate as many autocomplete classes are there are possibilities. This is kind of hacky and won't work for user-picked options)
The text was updated successfully, but these errors were encountered: