Opened 12 years ago

Closed 4 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)

4417.patch (1.2 KB) - added by Douglas Hays 11 years ago.
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

Download all attachments as: .zip

Change History (13)

comment:1 Changed 12 years ago by bill

Milestone: 2.0

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.

comment:2 Changed 12 years ago by bill

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:3 Changed 12 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:4 Changed 11 years ago by Douglas Hays

Milestone: 1.31.2
Owner: set to Douglas Hays
Status: newassigned

Changed 11 years ago by Douglas Hays

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 11 years ago by Douglas Hays

Summary: ComboBox and FilteringSelect lose IDs[patch][ccla]ComboBox and FilteringSelect lose IDs

comment:6 Changed 11 years ago by bill

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 11 years ago by Douglas Hays

Milestone: 1.2future
Status: assignednew

comment:8 Changed 9 years ago by bill

Component: DijitDijit - Form

comment:9 Changed 6 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:10 Changed 6 years ago by Douglas Hays

Status: assignedopen

comment:11 Changed 4 years ago by dylan

Milestone: future1.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 4 years ago by bill

Resolution: patchwelcome
Status: openclosed

I can see the value, but no plans to work on it.

Note: See TracTickets for help on using tickets.