Opened 13 years ago

Closed 7 years ago

#10357 closed enhancement (patchwelcome)

dijit.form.Forms should know their child form Elements by Name.

Reported by: Pete Smith Owned by:
Priority: high Milestone: 1.13
Component: Dijit - Form Version: 1.4.0b
Keywords: Cc:
Blocked By: Blocking:


standard form js dictates that

form.elementName = the Form Element DomNode?.

I have gone through grief to accomplish the same thing with all dijit forms and elements, like:

var mySelectDijit = this.getChildren().filter(function(w){ return w.attr('name') == 'your_data_or_mine';})[0];

I am proposing that all dijit.form's mimic this behavior of it's children by name="". So, I could use this by: (this being a dijit.form.Form)


so the code above could be eliminated by this.your_data_or_mine. This is a dijit, not a domNode and forms should know their children. It should only index the elements that are of type formValueWidget.

Change History (14)

comment:1 Changed 13 years ago by bill

Sounds useful, although I wonder if an API like myForm.getChildByName("foo") is more appropriate. The this.formElementName interface is convenient and could be implemented in Form.startup(), but it would be problematic if the form contents change dynamically.

comment:2 Changed 13 years ago by bill

Milestone: tbd1.5

comment:3 Changed 13 years ago by Pete Smith

Fantastic solution. I like the idea of trying to mimic regular form behavior, but I see your point about dynamic stuff. Forms and their named elements must be able to communicate. It would be nice as well to have all form dijits know their parent form, just like regular dom. An input element say could have this.form, and then I can find another form element by its name. Say an input element needs to know the value of its neighbor, it is onclick="this.form.neighbor.value". All I guess we would need is a pointer to its parent form, and then I can use your api method on the form dij. Right?

comment:4 Changed 13 years ago by bill


I know that name is the proper way to access fields inside a form but is there some reason you don't just want to give them an id and then call dijit.byId(...)?

comment:5 Changed 13 years ago by Pete Smith


Yes, giving an ID adds more work, but also adds id collisions in cases where you have multiple forms on the page. For example, I have a "live editing" sort of table, where you drill into a row and can edit the fields. If I use Ids, I have the collision problem of repeated dijit ids. I tried doing say _{$uniqueID} but it got cumbersome and problematic with ajax refreshes of the table (say filtering down the results with a search, the id is repeated). So now I rely solely on names of elements and their parent form.

comment:6 Changed 13 years ago by bill

I see.

Note to self: should look at dojox.fom.manager to see how it does these things / what method names it uses.

comment:7 Changed 12 years ago by Adam Peller

Milestone: 1.51.6

comment:8 Changed 11 years ago by bill

Milestone: 1.61.7

comment:9 Changed 11 years ago by bill

Milestone: 1.71.8

running out of time for 1.7

comment:10 Changed 11 years ago by bill

Component: DijitDijit - Form
Owner: set to Douglas Hays

comment:11 Changed 10 years ago by Douglas Hays

Milestone: 1.8future

Patches are welcome

comment:12 Changed 8 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:13 Changed 8 years ago by Douglas Hays

Status: assignedopen

comment:14 Changed 7 years ago by dylan

Milestone: future1.12
Resolution: patchwelcome
Status: openclosed

Given that no one has shown interest in creating a patch in the past 5+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.