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: |
Description
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)
this.formElementDijitName.
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
comment:2 Changed 13 years ago by
Milestone: | tbd → 1.5 |
---|
comment:3 Changed 13 years ago by
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
Right.
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
Bill,
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
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
Milestone: | 1.5 → 1.6 |
---|
comment:8 Changed 11 years ago by
Milestone: | 1.6 → 1.7 |
---|
comment:10 Changed 11 years ago by
Component: | Dijit → Dijit - Form |
---|---|
Owner: | set to Douglas Hays |
comment:12 Changed 8 years ago by
Owner: | Douglas Hays deleted |
---|---|
Status: | new → assigned |
comment:13 Changed 8 years ago by
Status: | assigned → open |
---|
comment:14 Changed 7 years ago by
Milestone: | future → 1.12 |
---|---|
Resolution: | → patchwelcome |
Status: | open → closed |
Given that no one has shown interest in creating a patch in the past 5+ years, I'm closing this as patchwelcome.
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.