Nick, It's harder than that:
Answer's integrated. >Working on this bug, where addItemAt / addItem on the XMLListCollection was >not parenting all the children properly. In particular, it was updating the >XML Parents of items that were not modified (rather, were simply bumped to a >later position on the list). Nope, XMLList is re-parenting items, not us. They were being bumped to a later position because XMLList doesn't technically support the idea of inserting a new node. That's where all the issues come from. >I have a branch of develop that fixes this, however, I want to pose a question >to the list : Double check that this doesn't break the original issue that caused this fix. However, I can see that your solution will have problems with XMLList's where each node has a different parent. XMLList reparents each time you replace any node. > - Do we NOT reparent the item added to the list? If this is the option, then > the user will have to do this by hand. This is probably the safest route, > but the parent will be null. It doesn't work that way. You in fact, can't. XMLList, not our code is reparenting things. Read the really long comment I added to the issue on how XMLList works with parents. ALL items added to a list get a parent and you have no choice. In the existing bug, the parent is being re-assigned _by the XMLList_ not by us to null because it moved into a previous position in that list that was null. > - If we DO parent the item added to the list - Do we always parent it to the > root node of the XMLList that it was added to (this is an assumption), or do > we try and guess based on other elements in the list? No. You can't know what the parent is. In an XMLList each node can have a different parent. There is not root node of an XMLList, that is the defining aspect of an XMLList, it's not XML, no root node... The only time the parent() method of XMLList returns something is when the XMLList contains all nodes with the same parent, which is a single case. It's normally just a collection of nodes with different parents. Further you have _no_ control over this. The XMLList class (FLASH PLAYER) decides the parent when you add it to an XMLList. When you have a moment, please read my comment on how this works. It's on the issue. > - If we DO parent it to another item, then it will change the parent of any > other items this item was copied from. XML items are copied by reference > (not by value), unless copy used the .copy() function on the XML object. > This means that if I do the following code : Not exactly, but it will cause a mess. If you attempt to reparent it, you will remove the original XML node from its parent structure... but, in Flash Player, XML nodes can actually have multiple internal parents but only one externally visible one. If you copy it you break the whole XML association which makes the practical use cases of XMLListCollection invalid. Its most often used to represent and filter and XMLList which is derived from an e4x expression. That would mean the original nodes used to create the XMLListCollection would be by reference and the added nodes copies. It would be a really big mess. >Just wanted to see how I should go with this. By fixing the bug (which is a >bug), I stand to break code either way that I go -- depending on expectations. There are a few other ways to go. The root cause is addItemAt(). There is no such concept for an XMLList. The second root cause is that XMLList is almost treated as a primitive, but it is an Object and that causes some issues. 1) Internally, at a certain point, all collection classes maintain an array of the expected order when a sort function is applied. We could always add the new node to the end of the XMLList (which is supported by Flash Player) and then use the collection's ordering mechanism to represent it in the order specified by addItemAt. This would work best from the concept of a collection in my mind. 2) We could create a new XMLList and add items to it from the original with the new item in the correct location. The problem with this is that, if someone had grabbed the source property, it will now change #1 would preserve compatibility with someone grabbing the source but at the expense of us always treating it like a sorted collection. #2 would be the easiest, but it means it would work differently than ArrayCollection and it will cause issues if people grab the source If you want to talk through this let me know. I have tons of experience with XMLList and this collection and with the use cases in my own system that I know can/will break depending on how we use it. The existing bug fix was to naïve for sure but all of the other variations have other problems too. Consider #1 and tell me where your concerns are. In everything I have thought through so far, it seems like the best choice. Mike
