I haven't looked at the failing tests, but could it be true that those tests are not using XMLListCollection directly? They may wrap the XML in an XMLListCollection or just pass XML directly into the control where it gets wrapped, and then they manipulate the XML? I think there are lots of people doing that sort of thing so we should not break them.
You could be right that nobody really uses XMLListCollection today to add/remove items. If you want to gamble that that is the case, I'm willing to go along with that, but we should at minimum find a way that folks doing the XML manipulation directly don't get broken. -Alex On 6/6/14 3:19 PM, "Michael A. Labriola" <labri...@digitalprimates.net> wrote: >>Are you saying that using XMLListCollection APIs to modify the source >>data has always been broken, or that you didn't like the behavior in how >>it >set up the parent? If there is some debate on what the behavior >>should be then there probably needs to be a flag to control that >>behavior. If it >was just plain broken, is there no way to make it work >>in both cases, like set a flag on the XMLListAdapter to tell it that the >>collection is about to >do mutation and therefore not react to some of >>the notifications? > > >XMLListCollection mangled, destroyed and in other ways violated the XML >structures the nodes originated from. It worked in the simplest test >cases only and, in practice, caused more problems than it solved. The >test cases present for the framework never noticed the side effects that >this code was having outside of the XMLListCollection itself, so, while >the tests made things appear to be working well, the rest of the >application was being trashed in many cases. > >Nick's fixes are trying to walk a line to fix XMLListCollection in a way >that it is still a viable collection but at the same time not cause >massive damage to other data through its use. It might not even be >possible but that's what he was doing. The problem with all of this is >that it's not an array, its XML and the rules around how XML nodes work >are completely different. This entire class and implementation is now and >always was broken. We were never able to use it in production apps >because of the side effects and had our own collection implementations >when we needed XML to work in controls. > >I do understand wanting to keep things working for existing users, >however, the problem is that the way it was working was actually causing >problems that they just haven't yet discovered. > >Mike >