Opened 13 years ago
Closed 5 years ago
#4417 closed enhancement (patchwelcome)
[patch][ccla]ComboBox and FilteringSelect lose IDs
Reported by: | guest | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.13 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | ComboBox FilteringSelect id | Cc: | |
Blocked By: | Blocking: |
Description
With a <select><option> construction in plain old HTML, it is possible to provide an ID with each option. When Dojo converts the whole thing to a table, the IDs are not preserved. It would be very handy to use these IDs to stylize the DIVs that Dojo creates to contain the options. Without them it is very difficult to differentiate between the options and give them, for example, different colors. Please consider passing the IDs through to the DIVs.
Attachments (1)
Change History (13)
comment:1 Changed 13 years ago by
Milestone: | → 2.0 |
---|
comment:2 Changed 13 years ago by
I suppose we could provide a getLabelClass() callback like Tree has. But actually there's already a _getMenuLabelFromItem() function that you could override.
As for the parser of <option> tags (which converts them into a trivial datastore), I guess we could enhance that to add id to each item.
comment:4 Changed 12 years ago by
Milestone: | 1.3 → 1.2 |
---|---|
Owner: | set to Douglas Hays |
Status: | new → assigned |
Changed 12 years ago by
Attachment: | 4417.patch added |
---|
id's were already being added in createOptions, so now just ask if the store if it has anything better to use before using the auto-generated id
comment:5 Changed 12 years ago by
Summary: | ComboBox and FilteringSelect lose IDs → [patch][ccla]ComboBox and FilteringSelect lose IDs |
---|
comment:6 Changed 12 years ago by
Hmm, I want to be careful with this. It has pretty far reaching effects I think, since it affects ComboBox's behavior with any store, not just dijit.form._ComboBoxDataStore.
The terms are confusing. For dijit.form._ComboBoxDataStore, the markup's value attribute becomes the store item's id. Ex:
<option value="CA">California</option>
maps to
{id: CA, name: California}
If there was an id attribute in the source markup (ex: <option value="CA" id="foo">California</option>
) then it would need to be represented in the data store some other way, maybe an attribute name like domId.
The other thing is that I'm uneasy about just adding in id's when the developer hasn't asked for them to be added in, since the added might conflict with some other id in the document and break calls in the developer's code like dojo.byId("foo")
.
So, perhaps start by supporting a feature that if a (store) item has domId (and domClass?) attributes, then write them into the generated DOM as id and class attributes? And then beef up dijit.form._ComboBoxDataStore to create those attributes in items if they exist in the original markup?
comment:7 Changed 12 years ago by
Milestone: | 1.2 → future |
---|---|
Status: | assigned → new |
comment:8 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
comment:9 Changed 7 years ago by
Owner: | Douglas Hays deleted |
---|---|
Status: | new → assigned |
comment:10 Changed 7 years ago by
Status: | assigned → open |
---|
comment:11 Changed 5 years ago by
Milestone: | future → 1.12 |
---|
Bill, is this worth keeping open, or close it out? I'd say we should close it unless we actually plan to work on it.
comment:12 Changed 5 years ago by
Resolution: | → patchwelcome |
---|---|
Status: | open → closed |
I can see the value, but no plans to work on it.
In general the elements come from a datastore so you can't specify the id's like that, although I guess you could specify them another way. Probably not interested in adding this feature unless a lot of other people need it.