Ticket #4417 (new enhancement)

Opened 15 months ago

Last modified 4 months ago

[patch][ccla]ComboBox and FilteringSelect lose IDs

Reported by: guest Owned by: doughays
Priority: normal Milestone: future
Component: Dijit Version: 0.9
Severity: normal Keywords: ComboBox FilteringSelect id
Cc:

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

4417.patch (1.2 kB) - added by doughays 4 months 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

Change History

Changed 15 months ago by bill

  • milestone set to 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.

Changed 14 months 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.

Changed 10 months ago by alex

  • milestone changed from 2.0 to 1.3

Milestone 2.0 deleted

Changed 4 months ago by doughays

  • status changed from new to assigned
  • owner set to doughays
  • milestone changed from 1.3 to 1.2

Changed 4 months ago by doughays

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

Changed 4 months ago by doughays

  • summary changed from ComboBox and FilteringSelect lose IDs to [patch][ccla]ComboBox and FilteringSelect lose IDs

Changed 4 months 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?

Changed 4 months ago by doughays

  • status changed from assigned to new
  • milestone changed from 1.2 to future
Note: See TracTickets for help on using tickets.