Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 66297 invoked from network); 26 Feb 2002 18:26:13 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Feb 2002 18:26:13 -0000 Received: (qmail 737 invoked by uid 97); 26 Feb 2002 18:26:13 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 721 invoked by uid 97); 26 Feb 2002 18:26:13 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 710 invoked from network); 26 Feb 2002 18:26:12 -0000 Date: Tue, 26 Feb 2002 18:27:12 +0000 Subject: Re: [Betwixt] ID-IDREF solution to cyclic reference problem Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <017601c1be87$503dbbd0$9865fea9@spiritsoft.com> Message-Id: <73E9A0D8-2AE6-11D6-8618-003065DC754C@mac.com> X-Mailer: Apple Mail (2.480) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N hi james On Tuesday, February 26, 2002, at 05:33 AM, James Strachan wrote: > From: "robert burrell donkin" >> i should probably say something about the changes to >> org.apache.commons.betwixt.io.BeanWriter since they are quite extensive. > i' >> ve tried to separate the actual writing from the logic concerning >> processing the descriptors . the writing code should now live in small >> expressXXX methods and some duplication has been reduced. > > Cool. > > I've been musing over possible ways to make it easy for users of betwixt > to > 'walk' the XML tree for a certain bean. Maybe once there's a few different > ways of outputting a bean, text, SAX & DOM (*) then we could maybe > refactor > the code to make it easier & share code. Just thinking aloud here... this is pretty much what i was (am) thinking too :) the logic's too complex to get right in different places without sharing. i'd like to pull out all the logic into an abstract superclass which will call expressXXX type methods. this should make it easier to implement other ways of output since it should be clear which methods are required. i agree that the signatures will be probably change a lot once we start looking at different implementation but hopefully they'd give us some sort of basis to start with. - robert -- To unsubscribe, e-mail: For additional commands, e-mail: