Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 5481 invoked from network); 28 Sep 2003 17:23:27 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Sep 2003 17:23:27 -0000 Received: (qmail 75594 invoked by uid 500); 28 Sep 2003 17:23:15 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 75455 invoked by uid 500); 28 Sep 2003 17:23:15 -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 75442 invoked from network); 28 Sep 2003 17:23:14 -0000 Received: from unknown (HELO smtp-out6.blueyonder.co.uk) (195.188.213.9) by daedalus.apache.org with SMTP; 28 Sep 2003 17:23:14 -0000 Received: from localhost ([82.38.66.131]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.5600); Sun, 28 Sep 2003 18:23:18 +0100 Date: Sun, 28 Sep 2003 18:25:34 +0100 Subject: Re: [beanutils] some ideas Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <00ad01c38594$39f30df0$edd4fea9@radpbi.bah.com> Message-Id: X-Mailer: Apple Mail (2.482) X-OriginalArrivalTime: 28 Sep 2003 17:23:18.0378 (UTC) FILETIME=[353E34A0:01C385E5] 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 On Sunday, September 28, 2003, at 08:43 AM, Sgarlata Matt wrote: > ----- Original Message ----- > From: "Henri Yandell" > To: "Jakarta Commons Developers List" > Sent: Saturday, September 27, 2003 10:39 PM > Subject: [beanutils] some ideas >> Solutions could be either: >> >> 1) Improve the system for the mapping converters so it is many-to-many. >> >> 2) Create a hierarchy structure. A ConvertUtilsBeansConverter could be >> plugged in to handle a class, and would contain its own batch of >> Converters. >> >> Any ideas? > > I think the Converter interface is fine, but could perhaps use some better > documentation and examples (in the JavaDoc... the converters in the > distribution seem more general-purpose than will be the converters a user > needs to create). I do like the idea of adding a new > ConvertUtils.register(Converter, Class from, Class to) method. this (and related issues) have come up before. i've thought about this quite a lot and i'm in favour of making the conversion pluggable strategy. this would allow both different and more sophisticated conversion algorithms to be created without breaking backwards compatibility. i don't realistically have the time to go about the creation of new implementations right now but i can certainly point people in the right direction if they want to go down this route. BTW stephen has talked before about creating a separate component that would provide sophisticated solutions to the issue posed by conversion. it might be a good idea to involve him in any design discussions. i now also that ted (of struts fame) is interested in the conversion problem so there may be enough momentum to at least think about creating a dedicated component. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org