I’d like to share with you the latest changes I’ve made to the Select2 APEX plugin. In case you wonder what I am talking about, have a read through my introductory article on the plugin here. I first of all updated the Select2 library files to version 3.4.3 to keep up with the latest features and bug fixes. Then I also fixed a bug in my own code that caused special characters to be escaped incorrectly. I simply dropped the Has Escape Special Characters attribute and let Select2 itself take care of special characters.
Now, the main reason I wrote this article is to highlight two new features you should know of. The first one is all about events. All kinds of events are getting fired while interacting with a Select2 page item. For example, the select2-highlight event is fired whenever you hover over an option in the dropdown. Before version 2.1, it was impossible for dynamic actions to capture these events, as they weren’t registered in the plugin. I eliminated this shortcoming by adding the below list of events to the plugin.
- change – fired when the selection is changed
- opening – fired before the dropdown is shown
- open – fired after the dropdown is shown
- highlight – fired when a choice is highlighted in the dropdown
- selecting – fired when a choice is being selected in the dropdown
- clearing – fired when a choice is being cleared in the dropdown
- removed – fired when a choice is removed or cleared
- focus – fired when the control is focussed
- blur – fired when the control is blurred
So it’s now possible to create a dynamic action based on one of these events. That means you can execute any action you want as a result of a Select2 event getting triggered on a particular page item. Some events contain additional data parameters that are accessible via the this.data object. The highlight event for example comes along with val and choice. So this.data.val would give you the ID value of the option you’re hovering over and this.data.choice is an object that contains detailed information on the option being hovered. More information and a live example can be found on the documentation page.
The other new feature was introduced by Martin Giffy D’Souza and makes it possible to determine whether the display or return column of the LOV is used as the return value of a Select2 item in tagging mode. Before version 2.2, the return value was always based on the display column. That makes sense since tagging mode allows new values to be entered and it’s obvious that these new values don’t have an ID assigned. That’s why we revert to the display values as the source for the return value.
However, it’s now possible to change this behaviour by selecting the Return Column in the newly added setting Return Value Based on. This time, the ID’s of selected pre-existing options will be used in the return value. Newly added values will still rely on their display value to be part of the return value.
Here’s a little example in case my explanation was a bit confusing. Imagine you’d have a Select2 item of type tagging support with the following LOV definition:
SELECT ename, empno FROM emp ORDER by 1;
I select the pre-existing values KING and ALLEN, and I also add Nick, a newly added value, to the list. This is how the return value looks like when the Return Value Based on setting is set to Display Column:
And the return value when the setting is set to Return Column:
You can clearly see the difference between both return values. The first one is composed of display values, while the second one is a mix of both ID and display values.