Override jQuery val() to avoid need specialized $("...").select2("val") about select2 HOT 10 CLOSED

isnt overriding core function something frowned upon by the jquery community?

from select2.

I understand it may not be well seen by many, but if done right i think the plugin user may thanks for it. :)

btw, above snipped was only tested with jquery-1.7.2, haven't take a look if compatible with 1.4

from select2.

@justindujardin any problem with this on 1.4.x?

from select2.

I agreed with this initially but after some further thought I realized this is not really a good practice. You would be triggering the above code for every single use of .val() which could amount in lots of unnecessary overhead (or conflicts, of other people get the same idea).

If you could override the method for ONLY select2 elements this might have made more sense, but since that's inherently impossible (because every time you select the dom you create a new jQuery object).

from select2.

added together with the fact that .val() should still work on the original element - since the values are synced - is this really necessary. albeit calling val() on original will only get you the ids, not the actual objects.

from select2.

@ivaynberg i was using 1.0 of select2 and i found val was not sync with the original element, that's the reason of the proposed changes.

from select2.

@ProLoser If other people get the same idea, that would introduce the overheat either way. (Agree with you)

What i'm really after is that people should really not care if they are dealing with enhance selec2 element or not when calling the val() or val("value").

from select2.

I think nothing stops you from calling .val() on the form input and it being what you expect it to be. The only thing is setting the value is not translated to Select2, however setting the value of the select and then doing .trigger('change') DOES in fact update select2. This was actually addressed by myself and Ivan in an earlier ticket

I think this is a bit more sensible and less overhead because then the reverse-update is only performed when actually necessary, and it hooks into the whole events system, meaning MULTIPLE elements, plugins, whatever that have been binded to the form input can do whatever it is they need to do. I believe that hooking into a 'change' event is a better, more common-practice-accepted approach to delegating changes to other plugin, and creates no conflicts.

from select2.

@ProLoser i see your point, i guess the less painful path is just add an extra line .trigger("change"), whenever the form input is touched programatically.

from select2.

That's how I'm doing it. I think it makes more sense when you have
everything binding to change events and click events in a uniform fashion.

On Fri, Apr 27, 2012 at 12:08 PM, Juan C. Garcia M. <
[email protected]

wrote:

@ProLoser i see your point, i guess the less painful path is just add an
extra line .trigger("change"), whenever the form input is touched
programatically.

---

Reply to this email directly or view it on GitHub:
https://github.com/ivaynberg/select2/issues/49#issuecomment-5388270

from select2.