Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 51479 invoked from network); 22 Aug 2005 16:11:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Aug 2005 16:11:37 -0000 Received: (qmail 94491 invoked by uid 500); 22 Aug 2005 16:11:36 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 93897 invoked by uid 500); 22 Aug 2005 16:11:35 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 93884 invoked by uid 99); 22 Aug 2005 16:11:34 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Aug 2005 09:11:34 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.123.75.163] (HELO sosnoski.com) (206.123.75.163) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Aug 2005 09:11:51 -0700 Received: from [192.168.0.2] (pool-71-112-83-113.sttlwa.dsl-w.verizon.net [71.112.83.113]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id j7MGBSRw005833 for ; Mon, 22 Aug 2005 12:11:29 -0400 Message-ID: <4309F967.3010906@sosnoski.com> Date: Mon, 22 Aug 2005 09:12:23 -0700 From: Dennis Sosnoski User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: axis-dev@ws.apache.org Subject: Re: [Axis2] Databinding API issues References: <43057D69.2050508@sosnoski.com> <430947EE.20108@gmail.com> <43096C13.7060805@sosnoski.com> In-Reply-To: <43096C13.7060805@sosnoski.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dennis Sosnoski wrote: > ... > I understand the virtual nature of OM. I'd like to take advantage of > that when writing the actual serialized output, so that the OM stays > virtual when used for the output of a databinding operation. It looks > like this should be very easy to implement, though - I assume you're > using the OMNode.serialize() method for actually writing out the data, > right? Then it should be just a matter of implementing a custom > OMElement for each data binding framework, which knows how to > serialize out a saved data object to an XMLStreamWriter when the > serialize() method is called. Actually, on thinking this over it shouldn't even require a custom OMElement for each data binding framework. Instead, it only requires a standard interface with a writeObject(XMLStreamWriter) method which each DataBindingSupporter class can implement. Then a single OMBindingElement subclass can be added to use this interface. - Dennis