>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
