xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allman, Michael" <Michael.All...@ssa.gov>
Subject RE: deprecated methods
Date Thu, 15 Jan 2004 15:59:00 GMT
Hi David,

I've responded in-line below.

> (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.

As a cat, does an ape have four legs or two?

As a JavaBean, does XmlInt have properties called longValue,
bigIntegerValue, bigDecimalValue?

Consider the following code fragment:

  XmlInt xmlInt = someObjectWhoseClassImplementsXmlInt;

  xmlInt.setIntValue(1);
  xmlInt.setLongValue(2);

  System.out.println(xmlInt.getIntValue());

What does the last line print?  If xmlInt behaves like a JavaBean, I would
expect it to print "1".

You've conceded that XmlInt is not a JavaBean.  Now I'm arguing that it
doesn't even behave like one, either.

> (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.

So?  If you want a JavaBean, wrap your XmlInt or what-have-you in a bonafide
JavaBean.  In fact, this way you can eliminate the problem I point out above
with the extra "properties" longValue, etc. by simplying exposing getters on
your wrapping JavaBean for "intValue" (or int) and "units" and nothing else.
How does that sound?

And what happens if one of these JavaBean tools or web containers tries to
serialize a simple XmlInt instance because it thinks (for one reason or
another) that it has a JavaBean on its hands?  Unless the instance does
indeed implement Serializable, it's going to barf!

Basically, my viewpoint comes down to this:

1.  XmlInt is not a JavaBean.  XmlInt doesn't behave like a JavaBean.
Trying to make it look like one just confuses the API.

2.  If you want a JavaBean based on XmlInt, make one and put an XmlInt
inside.  Wrapping actually boosts encapsulation in this instance by only
exposing the getters/setters that the bean provider decides the bean
consumer (say, a JSP writer) should care about.

Thanks, David.

Michael

- ---------------------------------------------------------------------
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