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 Mon, 19 Jan 2004 21:21:04 GMT
Michael,

Following up further on getIntValue/etc.

I went back to Eddie O'Neil (a bea colleague), who was one of the people who
ran into the problem with intValue() which lead us to the idea of changing
to getIntValue().  Eddie is using XMLBeans within a struts-based tool.

Eddie's explanation of the issue is pasted below. (Eddie, I hope it's OK
that I am forwarding your note to the list.)

I want a design that passes all the philosophical and purity tests, and I
agree that "nonorthogonal properties" are not a great thing.  But you'd
probably agree that, for XMLBeans to be useful, we need make sure the design
solves the pragmatic issues above all.  (I think we've done a pretty good
job at balancing pragmatism and purity in XMLBeans so far.)  Along those
lines, I still don't see any better alternative to the getIntValue()-style
solution to the struts/JSP 2.0 binding problem that Eddie describes below.
Do you see how the design falls out of the struts binding issue?

David

[Eddie's note below]

> ----- Original Message ----- 
> From: "Eddie O'Neil"
> To: "David Bau" <david.bau@bea.com>
> Sent: Monday, January 19, 2004 12:37 PM
> Subject: Re: Remember the XmlInt.getIntValue bug?
>
>
> > David--
> >
> >   Hey, good to hear from you.
> >
> >   You're right about what the problem was -- we (and Struts) bind to
> > JavaBean style properties on objects.  This is an issue in Struts in
> > general and will be an issue with binding to XMLBeans using the JSP 2.0
> > expression language as well -- both use the JavaBean naming conventions
> > for accessing properties on objects.  So, something named "intValue()"
> > wouldn't be accessible in a regular Struts application if it was exposed
> > on an object that was wrapped in an action form.  In JSP 2.0, for
> > example, if you have an XMLBean and want to access the value of such a
> > simple type with an attribute, you would want to use this expression:
> >
> >   {request.poXmlBean.order.total.intValue}
> >
> > on a document that looks like:
> >
> > <order>
> >     <total currency="USD">59.95</total>
> > </order>
> >
> > in order to get to 59.95.
> >
> >   Feel free to correct my example, but that's the general idea.
> >
> >   I can sort of see Michael's point, but it's not a simple matter of
> > purity.  The argument that this code modifies two distinct fields in an
> > object doesn't seem to hold to me:
> >
> > xmlInt.setIntValue(1);
> > xmlInt.setLongValue(2);
> >
> > I would expect that this code would do whatever the bean's documentation
> > and (hidden!) underlying implementation says that it does -- it doesn't
> > imply that the implementation of the bean maintains two distinct private
> > fields -- intValue and longValue.  Consider:
> >
> > public class Name
> > {
> > private String firstName;
> > private String lastName;
> >
> > String getFirstName() ...
> > String getLastName() ...
> > String getName() ...
> > }
> >
> > Michael's stance would mean that "getName()" shouldn't be a JavaBean
> > property because it means that there would need to be a "name" as a
> > private field where in this case name is implemented as:
> >
> > public String getName()
> > {
> >     return getLastName() + ", " + getFirstName();
> > }
> >
> > There is value in being able to do getName() just like there's value in
> > being able to expose a single bit of data stored in an object in many
> > different ways.
> >
> >   Tools and binding languages have gravitated toward the JavaBean spec,
> > right or wrong.  As a result, it would be a shame to have a great way to
> > compile an XSD and consume an XML document but no way of binding to said
> > document without adding another layer atop it that then exposes the XML
> > to a binding language.
> >
> >   Does that make sense?
> >
> > Eddie


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