I would actually consider an exception thrown because of attribute ordering to be a bug prior to getRoot or readObject in the serializer. I ran into the same issue on some component's I authored but I realized I had to be robust.
Even in the DI containers such as spring, you have to be robust despite attribute ordering specification issues. This does seem to motivate a good init protocol across the tree prior to returning from getRoot and readObject. -----Original Message----- From: Michael Allman [mailto:[email protected]] Sent: Tuesday, August 03, 2010 2:22 AM To: [email protected] Subject: Re: attribute ordering On Tue, 27 Jul 2010, Greg Brown wrote: >> Call me naive or maybe just a newb but I didn't know that the order in which attributes appear on an element in bxml mattered. I mean, in XML >> >> <element attr1="d24" attr2="hahth"/> >> >> and >> >> <element attr2="hahth" attr1="d24"/> >> >> are the same when considering each document's infoset. > > That may be true, but in the DOM order has relevance. Attributes are > stored as a list, not a map. Pivot's org.apache.pivot.xml.Element class > provides both keyed and indexed access to attributes. Huh? What language/implementation of the DOM are you referencing? I'm looking at Java's org.w3c.dom.Node, in which an element's attributes are represented by a org.w3c.dom.NamedNodeMap. The documentation for the latter explicitly states that NamedNodeMap does not imply an ordering. Anyway, a list is a map. Or to put it another way, any collection can be represented by a list simply by enumerating the elements of that collection in some way. That does not imply that that collection has some kind of innate or natural ordering. >> Yet there are clearly cases where the order in which the attributes are >> written is key. The one I ran into a moment ago is pretty simple. The >> following works >> >> <ListView listData="['One', 'Two', 'Three']" selectedIndex="0"/> >> >> while the following does not >> >> <ListView selectedIndex="0" listData="['One', 'Two', 'Three']"/> >> >> The latter throws an IndexOutOfBoundsException. Thoughts? > > The first one works because the list data is set before the selected > index. The second one fails because the list is empty when the selected > index is set. If ordering did not matter, we'd have no way to know which > attribute to set first. Exactly. There is nothing in the StAX spec that states that Attributes are indexed by the order in which they are written. Michael
