xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david....@bea.com>
Subject RE: deprecated methods
Date Thu, 15 Jan 2004 14:50:06 GMT
Hi Michael,

> After reading your arguments for getters/setters I'm still not convinced.
> It sounds like the decision hinged around JavaBean tool compliance.  I
don't
> know how that applies since XmlInt, for example, is not a JavaBean.

I think that's actually the core thing in the argument for the change, so
let's go into a bit.

The issue is - XmlInt didn't use to be a JavaBean, but it turns out it
needed to be. [Also, really when we use the word JavaBean, the issue
actually about being JavaBean-like, with standard-looking property accessors
nowadays.  Many tools today use reflection to search for methods called
"getX" without using JavaBeans introspection spec.]

Here are a couple examples where XmlInt clearly needs to be a JavaBean.

(1) XmlInt is designed to be a base class.  For example, if you have a
complex schema type with simple content that adds attributes to an int, like
this:

<xs:complexType type="unitized">
  <xs:simpleContent>
    <xs:extension base="xs:int">
      <xs:attribute name="units" type="xs:token"/>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

I.e. instaces are like this:

<myInt units="inches">4</myInt>

Then the generated interface would look something like

interface Unitized extends XmlInt
{
   String getUnits();
}

The question is, as a JavaBean, what should the properties of Unitized be?
Should it just be "Units"?

No, it seems like it should be
(1) Units is a String
(2) IntValue is the int.

(2) The other issue is when you're working with a struts-like environment
and you're trying to bind an XmlBean directly into a form.  If you have an
XmlInt laying around, no JavaBean-oriented binding tool is going to know
what to do with it.  I.e., it doesn't have any built-in knowledge about how
to convert an XmlInt into an int, and so it will be forced to punt.

To bind to an XmlInt, you'd need to go and modify other binding frameworks
out there - not so easy. However, if XmlInt exposes its underlying int via a
property of type "int", binding can be quite trivially easy to do, because
any self-repsecting binding framework should be able to call getIntValue().

-

Scenario #1 (extension) is really the thing that closes the case I believe
(and I think it's the situation where the problem originally came up).  That
is, simple content extension is really the reason XmlInt needs to be a
JavaBean-like interface - because it will be the base class for other
JavaBean-like interfaces.

David


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message