pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Allman <...@allman.ms>
Subject Re: attribute ordering
Date Tue, 03 Aug 2010 07:17:45 GMT
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
>> 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.


View raw message