On Tue, 3 Aug 2010, Noel Grandin wrote:
Michael Allman wrote:
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.
Michael is correct here:
http://www.w3.org/TR/REC-xml/#sec-starttags
Not sure that there is much we can do about it, unless we add some more
intelligence to the serialiser, so it knows what order to apply
attributes to beans.
Perhaps bean metadata? I don't know. You get into trouble when bean
properties depend on each other.
Another way to think of the example I gave is that "selectedIndex" is not
a proper writable bean property. Rather than a noun, maybe it should be a
verb, as in, public void selectIndex(int index)? However, this would
prevent its use as an attribute in bxml.
Another option would be to introduce an optional deserialization callback
to override the default (bean) deserialization behavior. In principal,
this would work similarly to the readObject(ObjectInputStream) method from
Java serialization, but would have a signature and behavior more suitable
to bean serialization. The callback would be declared on an interface,
and the bean would have to implement that interface.
Another option would be to ignore this problem and accept the fact that
attribute ordering is significant in bxml even through it's not in xml.
Aside from deviating from users' understanding of xml, this option will
require that users understand certain bean's property's dependencies and
put them in the correct order in their bxml file. Of course, this means
bean properties may not have circular dependencies. But then, if you're
creating a JavaBean you should know better.
Michael
