Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 58429 invoked from network); 12 Nov 2004 09:25:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 12 Nov 2004 09:25:06 -0000 Received: (qmail 67443 invoked by uid 500); 12 Nov 2004 09:25:04 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 67415 invoked by uid 500); 12 Nov 2004 09:25:04 -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 67396 invoked by uid 99); 12 Nov 2004 09:25:04 -0000 Received-SPF: pass (hermes.apache.org: local policy) Received: from [194.140.11.78] (HELO aries.informasa.es) (194.140.11.78) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 12 Nov 2004 01:25:04 -0800 Received: from capri.informasa.es (root@capri.informasa.es [194.140.11.70]) by aries.informasa.es (8.12.3/8.12.3/Debian-6.6) with ESMTP id iAC9OvSm020348 for ; Fri, 12 Nov 2004 10:24:57 +0100 Received: from [192.168.103.117] ([192.168.103.117]) by capri.informasa.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA16857 for ; Fri, 12 Nov 2004 10:24:57 +0100 Message-ID: <41948301.8020103@informa.es> Date: Fri, 12 Nov 2004 10:31:45 +0100 From: "Nacho G. Mac Dowell" Reply-To: igonzalez@informa.es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [Validator] Next Release References: <20041111201015.28204.qmail@web50406.mail.yahoo.com> In-Reply-To: <20041111201015.28204.qmail@web50406.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I would like to address the importance of bug #30955 (http://issues.apache.org/bugzilla/show_bug.cgi?id=30955). Currently, form definition processing isn't working properly. I was thinking of changing severity to major to raise attention. Please do take a look and tell me what you think. >I doubt form inheritance has been tested completely since it hasn't been >included in a release yet. > I have extensively used form inheritance (I sent the patch). If you take a close look at the changes involved you'd notice that special care was taken to minimize impact on the rest of the code. I beleive form inheritance could take Validator one step forward. If #30955 gets solved it would even get more useful. I know that it is out of the scope of this mailing list but I would like to say that using validator with struts is sort of painful when using DynaValidatorForm. You have at least 4 hard coded parameter definitions (struts-config.xml, validation.xml, the view and the action). I have seen that the preferred direction for validator is not form validation but bean validation. It would be nice though if we could have a single form definition with its simple commons-validator validations. What do you think? Should I post this in the struts mailing list? Nacho G. Mac Dowell PD: I am using a different email address since it's the only one I can use from work. --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org