-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
added enable, disable and deselect #1415
base: main
Are you sure you want to change the base?
Conversation
coffee/chosen.jquery.coffee
Outdated
@@ -102,17 +105,27 @@ class Chosen extends AbstractChosen | |||
@form_field_jq.removeData('chosen') | |||
@form_field_jq.show() | |||
|
|||
enable: -> | |||
@is_disabled = false | |||
@form_field.disabled = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems weird to me that this is setting the form field value after getting called by search_field_disabled
which just read that value. I couldn't really think of a cleaner way to do this, though, so I'm not 100% sure what to suggest to make it better.
Thanks @koenpunt. I'm definitely a fan of adding this functionality. |
coffee/chosen.jquery.coffee
Outdated
@@ -82,6 +82,9 @@ class Chosen extends AbstractChosen | |||
@form_field_jq.bind "liszt:updated.chosen", (evt) => this.results_update_field(evt); return | |||
@form_field_jq.bind "liszt:activate.chosen", (evt) => this.activate_field(evt); return | |||
@form_field_jq.bind "liszt:open.chosen", (evt) => this.container_mousedown(evt); return | |||
@form_field_jq.bind "liszt:enable.chosen", (evt) => this.enable(evt); return | |||
@form_field_jq.bind "liszt:disable.chosen", (evt) => this.disable(evt); return | |||
@form_field_jq.bind "liszt:deselect.chosen", (evt) => this.results_reset(evt); return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're going to need to merge master and switch from liszt
to chosen
here.
I've rebased on latest master and checked for chzn => chosen changes, so things should be good now |
coffee/chosen.jquery.coffee
Outdated
@container.removeClass 'chosen-disabled' | ||
@search_field[0].disabled = false | ||
@selected_item.bind "focus.chosen", @activate_action if !@is_multiple | ||
enable: -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should check whether it is already enabled, to avoid enabling it several times. Otherwise it will end with multiple focus listeners
|
And just realized I've created another problem by only enabling the select when it is not already enabled. Because this way the focus event will never be applied to already enabled select boxes.. |
this.close_field() | ||
else | ||
enable: -> | ||
if @form_field.disabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After @stof's comment, I was experimenting with this line over the weekend. As you point out in your comment, we can't simply check for disabled here because it skips the setup we need to do on our initial build. Two options I considered:
1: Pass a parameter when running the results_build
function.
search_field_disabled: ->
if @form_field.disabled
this.disable()
else
this.enable(true)
...
enable: (forceIt=false) ->
if @form_field.disabled or forceIt
2: Because the only problem with repeating this function is applying additional event listeners, we could store the return value of the bind function in a variable and only set it when it's empty. On disable, we'd empty it.
enable: ->
...
@boundSomething = @selected_item.bind "focus.chosen", @activate_action unless @is_multiple or @boundSomething?
disable: ->
...
@selected_item.unbind "focus.chosen", @activate_action unless @is_multiple
@boundSomething = null
I kinda hate both of these so I'm curious what you come up with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It occurs to me that #1 wouldn't solve the problem where listeners are getting repeated. Dang.
reset event is now deselect
added documentation for events
Added separate functions and events for enable, disable and reset, fixes #1131