xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Allman <...@nfcexperts.com>
Subject RE: deprecated methods
Date Tue, 20 Jan 2004 04:50:24 GMT
David,

I don't know struts so I can't evaluate Eddie's argument.  It's
frustrating that the limitations of JavaBeans are having such far-reaching
effects.  It seems everything that has anything to do with data these days
has to be a JavaBean.  I wonder if JSR 175 is going to change that?

I do think I understand the JavaBeans argument, and I think you understand
mine.  I admit I don't see a solution that would satisfy both sides.  So
let's leave it at that for now.  :)

Moving on to other things, do you know how (or if) BEA is going to
reconcile XMLBeans with JAX-RPC for J2EE 1.4 Web services support?  I'm
very curious because I'd like to use XMLBeans-derived interfaces for data
transfer and persistence in one of my gestating enterprise apps.  I've run
into the issue of using XMLBeans on a Web service endpoint.  Is there a
simple way to get XMLBeans and JAX-RPC 1.1 to play nice together?

On a related note, why doesn't XmlObject extends Serializable?  I feel
like I'm taking a chance passing an XMLBean over RMI.

Thanks,

Michael

On Mon, 19 Jan 2004, David Bau wrote:

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

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