#11144 closed defect (fixed)
ComboBox: different behaviour with labelFunc and labelAttr
Reported by: | richso | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.6 |
Component: | Dijit - Form | Version: | 1.4.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
dijit.form.ComboBox using labelAttr and labelFunc shows different behaviour after selected an option: labelAttr - display the searchAttr value but labelFunc - display the value return from labelFunc, see the attached example
Attachments (1)
Change History (12)
Changed 12 years ago by
Attachment: | combobox_faultcase.html added |
---|
comment:1 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Milestone: | tbd → future |
Summary: | different behaviour with labelFunc and labelAttr in dijit.form.ComboBox → ComboBox: different behaviour with labelFunc and labelAttr |
Hmm, that's true.
Neither labelAttr or labelFunc work well w/ComboBox (or FilteringSelect). It's a design issue.
labelAttr and labelFunc mostly work to control what markup is displayed in the drop down list, but I think the <input> field needs to display the searchAttr because when the user blurs the ComboBox, then ComboBox tries to do a lookup based on that string in the <input>. But if the <input> field just displays the searchAttr then having a custom label isn't very useful.
So, not sure what to do about this ticket, maybe the ComboBox needs to have two states, marking whether the input contains a label or a search string.
Still, that doesn't allow rich text in the <input> field which is what I was really after in the first place w/this labelAttr/labelFunc feature.
comment:2 Changed 12 years ago by
IMHO, even that its a design issue, labelAttr and labelFunc should function in the same way, i.e. either both shows the labelAttr / labelFunc return value or searchAttr after selection instead of labelAttr and labelFunc works in different way.
Also, here is some opinion on the design issue: FilteringSelect? and ComboBox? may display the searchAttr side by side with the labelAttr/labelFunc value, if the searchAttr != labelAttr otherwise display only one of them while the user is typing and then display the labelAttr / labelFunc value after the selection, e.g. something like:
A
ABC - Song of ABC ABS - Absolute
comment:3 Changed 12 years ago by
Oops ! the 'something like' got scrambled up after save...
The explanation for my opinion on the design issue is that the value from searchAttr should often in shorter form than the value from labelAttr / labelFunc as its to be used for locating the option easier and faster. That should not, in most case, added up the length of the list to be display while the user is typing.
comment:5 Changed 12 years ago by
Milestone: | future → 1.6 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
I agree that labelAttr and labelFunc should operate in the same way. Actually what's happening internally is that _announceOption() always calls labelFunc() to get the value to write into the <input> area, but strangely the default implementation of labelFunc() returns searchAttr.
I have no problem making them consistent; I'm just not sure whether the label or the search string should be copied to the input area. But I've got it working with copying the text version of the label (it may be HTML, and of course we don't want to copy tags). So I'll check that in.
comment:6 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 12 years ago by
comment:8 Changed 12 years ago by
comment:9 Changed 11 years ago by
(In [24211]) On further consideration, when selecting an item from the drop down list, write searchAttr into the <input> field rather than the label from the selected drop down item. The label in the drop down is by default searchAttr, but can be overridden by specifying labelAttr or labelFunc.
This reverts ComboBox? to the 1.5 behavior when labelAttr is specified, and makes Combox's behavior consistent when labelFunc is specified.
comment:11 Changed 11 years ago by
Component: | Dijit → Dijit - Form |
---|
fault case