Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 31282 invoked from network); 13 Dec 2002 00:58:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Dec 2002 00:58:24 -0000 Received: (qmail 1069 invoked by uid 97); 13 Dec 2002 00:59:38 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 1036 invoked by uid 97); 13 Dec 2002 00:59:37 -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 1001 invoked by uid 98); 13 Dec 2002 00:59:37 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DF930AF.4090602@schof.com> Date: Thu, 12 Dec 2002 19:58:23 -0500 From: Sean Schofield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [digester] i'd like to contribute - here's my new feature idea References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > I don't want to squash Sean's enthusiasm, but I don't yet understand > the need for this modification. Don't worry about my enthusiasm. I'm just throwing this out as an idea. I can take thoughtful criticism. If we nix this idea, I have some other ideas that I could contribute (eventually folks will like one of them and that will be where I start). > Robert's concern about the attribute is correct, because nothing > anywhere in XML guarantees the order of attributes for an element. > They're just a soup of names and values. I was only thinking of grabbing the first attribute because I was making the assumption that in that case it would be the only one (so order wouldn't be an issue.) I wasn't entirely comfortable with that idea, but that's why I threw it out there. > Couldn't Sean achieve his goals with the existing code and using > "java.lang.Object" as the base class? I hadn't thought of that! I think that would work nicely and it would be fairly obvious to somone studying my code what I was trying to do there. > While it's great to encourage participation, it's worth while to > exercise restraint with APIs. Couldn't agree more. We don't want to bloat these great Commons APIs with custom features for one or two programmers. I thought my problem was general enough (and it is) its just that everything I need is already there (although hard to find without a lot of documentation or examples). > Ultimately, if Sean really doesn't like the ObjectCreateRule, I would > suggest that in this case he should just write his own rule > implementation that behaves the way he needs it to. Now that I've pieced together how to do this with current code I agree with Joe that the patch isn't really necessary. Believe me, I did look over the existing code before charging in with a feature request. Perhaps I can make a contribution in the area of improved documentation (perhaps example programs) when the time comes for that? I've actually got a few other ideas I'm mulling over. I'll submit them to the group for consideration when they're a little more flushed out. Thanks for the help and feedback. Sean -- To unsubscribe, e-mail: For additional commands, e-mail: