Return-Path: Delivered-To: apmail-xml-xmlbeans-dev-archive@www.apache.org Received: (qmail 59308 invoked from network); 15 Jan 2004 14:50:16 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 15 Jan 2004 14:50:16 -0000 Received: (qmail 9848 invoked by uid 500); 15 Jan 2004 14:50:12 -0000 Delivered-To: apmail-xml-xmlbeans-dev-archive@xml.apache.org Received: (qmail 9815 invoked by uid 500); 15 Jan 2004 14:50:12 -0000 Mailing-List: contact xmlbeans-dev-help@xml.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: xmlbeans-dev@xml.apache.org Delivered-To: mailing list xmlbeans-dev@xml.apache.org Received: (qmail 9802 invoked from network); 15 Jan 2004 14:50:11 -0000 Message-ID: <004e01c3db76$de838150$1e00000a@lightbox> From: "David Bau" To: References: Subject: RE: deprecated methods Date: Thu, 15 Jan 2004 09:50:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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: I.e. instaces are like this: 4 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/