Opened 14 years ago

Closed 14 years ago

#5710 closed defect (fixed)

API changes and Inconsistancies w/ .setAttribute

Reported by: dante Owned by: bill
Priority: high Milestone: 1.1
Component: Dijit Version: 1.0
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by dante)

in [11982] several undocumented API changes were made.

onChange was removed for checkbox?

Checkbox widget.value never changes (always reports "on", but has both deprecated getValue() and setValue() methods?

new inconsistancies in the deprecated .getValue .setValue replacements exist as well:


does not work.


works, though throws deprecation warnings. varying combinations of the two on various dijit.form.* widgets have different results.

Code in FormWidget? is still calling the deprecated methods as well, which is probably why it is still working in some cases.

This should probably be addressed clearly in all points of documentation, and work before 1.1 beta.

Change History (9)

comment:1 Changed 14 years ago by dante

Description: modified (diff)

comment:2 Changed 14 years ago by Douglas Hays

Run dijit/tests/form/test_checkbox.html, and the 3rd checkbox has an onChange handler that fires when you check the box. onChange does not fire when you change the value attribute.

comment:3 Changed 14 years ago by Douglas Hays

Resolution: invalid
Status: newclosed

I think I'm confused as to what the problem is. For a checkbox, the value does not reflect whether the box is checked or not. This is just weird behavior that is normal for a checkbox. So iff the box is checked, then a form submit sends the checkbox name with value widget.value. If its not checked, then no value is submitted for the checkbox. onChange fires any time the box is clicked and the onChange paramneter is true or false to indicate whether the box is checked or not. There is no need to ever call a deprecated getValue or setValue with checkboxes since widget.setAttribute does the same. Maybe something needs to be documented better?

comment:4 Changed 14 years ago by dante

Resolution: invalid
Status: closedreopened

dijit.form.TextBox? inhers from _FormValueWidget and implements a getValue() method, and no apparent .value ? If it does have a value its a sideffect of inheritance, and not being checked? Postcreate uses setAttribute(value,v) but all other value handling is done by getValues()? or at least that's how it's documented. None of those public functions in that particular file have so much as summaries. You cannot inherit a summary from a inherited function like we have been planning/hoping for, nor should we be attempting to from deprecated functions.

do "real" checkboxes send name=value pairs when POST'd? seems like I've always expected a name==on, but have been wrong before.

the someTextBox example above illustrates a failure in using setAttribute/.value combination, as I am unable to set the value of one text box to the value of another textbox via dijit.byId() ... I was having to use .get/.setValue, which are deprecated. If this is the intended behavior, it's silly. .value is always null.

after looking again, it's just "entirely" inconsistent now. _some_ form widgets implement a setValue/getValue/getDisplayedValue combination, some are deprecated for setAttribute, checkbox's .value never changes as far as I can tell (but i'll have to investigate further).

the level of confusion introduced by the variety of methods of setting/getting data from form widgets makes it no better than standard DOM inputs, and is entirely counter intuitive.

comment:5 Changed 14 years ago by dante

yes, something needs to be documented better. please see the dijit book regarding form widgets:

perhaps you could assist craig in updating the relevant documentation on the website.

comment:6 Changed 14 years ago by Douglas Hays

Owner: changed from Douglas Hays to bill
Status: reopenednew

dijit.form.checkbox has a default value = "on" (not inherited, checkbox.js). Why did you say it was null? I'm confused. Is this a bug?
dijit.form.textbox has a default string value of "" (inherited form _FormWidget).
I was under the assumption that overridden public functions are not to be redocumented. It seems wrong to redocument these. Bill, should be go thru and copy documentation?
Real checkboxes send name=on, so do dojo checkboxes. Is there a bug here that I'm not aware of?
setAttribute prevents us from having a setDisabled, setReadOnly, setTabIndex, setMaxLength, blahblah. For checkboxes, setValue was deprecated just like setDisabled since its just an attribute that is never changed. This is different from TextBoxes? that have values that change often and are changed by users. CheckBoxes? are unique this way.
bill, can you sort out what needs to be documented?

comment:7 Changed 14 years ago by bill

Priority: highnormal
severity: criticalnormal

OK, I'll update the docs. Other than that we are good to go.

comment:8 Changed 14 years ago by bill

(In [12606]) Flesh out documentation about setAttribute() and setValue(). Refs #5710. !strict

comment:9 Changed 14 years ago by bill

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.