add sugar to dojo.NodeList

[alex]

as discussed in this week's IRC meeting, add syntactic sugar to dojo.NodeList? to make event connection, style setting, and iteration easier. Should land for 0.9.

[alex]

(In [10267]) start of checkins for syntatic sugar for dojo.NodeList?. This doesn't directly add sugar, but other methods will want/need dojo.connectPublisher(). Refs #4205

[alex]

(In [10268]) start of some syntatic sugar for NodeLists?. Makes connecting to common events easier as well as changing css class names on a list. Refs #4205.

[alex]

(In [10269]) allow dojo.forEach(), dojo.map(), and related functions to take strings as functions to execute. Need to investigate caching the resulting anonymous functions. Makes operating on NodeLists? much easier. Refs #4205

[tk]

Are there any more changes for this, or was a "fixes" forgot in the checkin message?

-Karl

[alex]

still need to add methods:

• attr
• removeAttr
• html (getContent?) setter/getter

[alex]

also consider parents() and siblings() and not()

[alex]

(In [11146]) making the constructor smaller ('cause we can), adding slice/splice, and moving animations out to dojo.NodeList?-ext. Refs #4480. Refs #4205. Fixes #4822

[alex]

(In [11147]) tests for slice/splice. Splice isn't working correctly on IE 6 yet (still digging). Refs #4822. Refs #4205

[alex]

(In [12596]) adding NodeList?.onfocus(). Refs #4205. !strict

[alex]

(In [12818]) shorten NodeList? code, add toggleClass(), and update documentation. Refs #4205. Refs #3961. !strict

[alex]

(In [12899]) adding sugar to dojo.attr(), and therefore to it's mapping into dojo.NodeList?. Expanding tests and docs. Supports a property-bag style for attrs the same way we do with dojo.style(). Refs #4205. !strict

[alex]

(In [12900]) ugg. Fingered the wrong test file when checking in [12899]. Refs #4205. !strict

[alex]

NodeList? is pretty sugary at this point. The only other major thing to land are Neil's behavior patches, but those are filed under separate cover.

[nathan]

OK - I don't know if reopening is the correct thing to do or not...but the changes in changelog [12899] breaks validation of dijit.form.Form.

For a test case, you can go to ​http://download.dojotoolkit.org/current-dev/dojo-release-1.1.0rc1/dijit/tests/form/Form.html and fill out an invalid date, and click on Submit. The validation will fail (it will tell you that the form is invalid) - but the form will submit anyway. There is no way to prevent the original form element from submitting.

If you change the dojo.connect on line 1092 to a node[name] = value, then everything is happy and it works as expected - that's roughly the way it used to work.

Can anyone shed any light on the reasoning behind that change?

[nathan]

A patch which will revert to the previous behavior. This is NOT probably the desired solution, but for any who are having problems with form submission, this may be an interim fix.

[nathan]

It seems like the issue is calling the function via a dojo.connect - which makes it impossible to return false from the connected function to cancel the actual submit from happening. It seems that this would happen as well for other functions attached to html elements (onClick, onKeypress, etc).

[alex]

don't return false, dojo.stopEvent() on the passed event object.

Not a bug.

[bill]

See #6299; we refactored Form to not use dojo.attr() and reinstated the ability to use "return false" as a way to cancel the form submit.