CollectionView adds items in backwards order
Reported by Christopher Swasey (endash) | November 10th, 2008 @ 10:24 PM
As the title says. I'm not entirely sure of the reason, or it's compelling, but it does break the use of last-child and first-child selectors, especially in grouped scenarios where you can't simply swap them around to accomplish your styling goals.
Just to clarify: this is a problem with the DOM order of the elements, not the display order (which is handled via absolute positioning of each element)
I'm going to investigate a bit more, but the solution should be as simple as modifying the loop to reverse the order by which the views get appended. After I've done a bit more investigating I'll attach a patch.
Comments and changes to this ticket
-
David Starke December 11th, 2008 @ 06:18 PM
It looks like CollectionView also does not make any attempt to maintain the DOM ordering of it's children when the content array is modified. If, for example, an object is inserted into the middle of the content array, a new child view is created, but it is appended to the CollectionView's child node list rather than placed at the correct index. This appears to also be true for other actions that rearrange or change the visibility of the ColectionView's contents.
-
Charles Jolley December 11th, 2008 @ 11:26 PM
- → Tag changed from “bug fix patch tests” to “expected-behavior”
- → State changed from “new” to “invalid”
This behavior is intentional. By not worrying about keeping the DOM elements in the same order as their content elements, the CollectionView can layout literally 2-3x faster.
The reverse layout of the DOM elements in CollectionView, while technically could be avoided, it left this way so you will notice that the DOM does not match the source order.
-
Christopher Swasey (endash) December 11th, 2008 @ 11:37 PM
Certainly this seems reasonable (FYI I'm not sure why the original tags were as such as I did not originally add a fix, patch, or test).
Perhaps a comment could be added to point out the intentionality of the behaviour. It's worth nothing that certain style behaviours cannot be realized without appropriate use of first-child and last-child selectors. If this behaviour is going to be broken, then an explanation seems appropriate.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
SproutCore: JavaScript Application Framework
Source available from github
The Git repository resides at http://github.com/sproutit
Check out the current development trunk with:
git clone git://github.com/sproutit/sproutcore.git
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Submitting Patches
Resist adding new tags, use the ones in the tag cloud already. If you are submitting a patch or a pull request from a fork, tag the ticket as a "patch". If you are submitting a new feature enhancement, tag it as "enhancement". If you are submitting a fix for a bug, tag it as "fix".
Thanks!
We're glad you're contributing. Feel free to drop by the Google Group as well to let us know you are involved.
