From adffaces-dev-return-1438-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 16 15:59:09 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 2824 invoked from network); 16 Oct 2006 15:59:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 16 Oct 2006 15:59:09 -0000 Received: (qmail 71817 invoked by uid 500); 16 Oct 2006 15:59:08 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 71740 invoked by uid 500); 16 Oct 2006 15:59:08 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 71531 invoked by uid 99); 16 Oct 2006 15:59:06 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Oct 2006 08:59:06 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of awiner@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Oct 2006 08:59:05 -0700 Received: by ug-out-1314.google.com with SMTP id y2so1036016uge for ; Mon, 16 Oct 2006 08:58:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=syr9A/dpScVeJQweJvjxtO3t4rfCuMViuQxjnmAiSA6rosRWa9tTVCHVyPa1qUqXZlMvvlM+1bC0RlyoeNlR4Fs+n5TJ4k9pVO7/luM9mfeQsyhZBKR7F/miwXzfbD4Jni6C2rvy8qZE+5VsoaE3brejEubEtPn4vGSs5+4tlN8= Received: by 10.66.255.7 with SMTP id c7mr8325498ugi; Mon, 16 Oct 2006 08:58:43 -0700 (PDT) Received: by 10.67.102.2 with HTTP; Mon, 16 Oct 2006 08:58:43 -0700 (PDT) Message-ID: <6dac79b90610160858n3a6a3f13r314f5644de86cba4@mail.gmail.com> Date: Mon, 16 Oct 2006 08:58:43 -0700 From: "Adam Winer" To: adffaces-dev@incubator.apache.org Subject: Re: Re: security issue w/ UIXEditableValue ? In-Reply-To: <5a99335f0610160422n7f771581ubf109b37b169b66@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <71235db40610131603k3c36052bvfe718e55c0db54ed@mail.gmail.com> <75e54f200610131636y1429589cwf699a676c84ede88@mail.gmail.com> <71235db40610140955w56a9c6b5tbacc5d5e12eb3d46@mail.gmail.com> <5a99335f0610142013w2f15fd3fufd7f48882b756a23@mail.gmail.com> <71235db40610150041p3e249399id896d46b18c1d747@mail.gmail.com> <5a99335f0610160422n7f771581ubf109b37b169b66@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Martin, You don't want the validator to be on the component with the values - once you've said that it's cross-component validation, that's just not the right place. For one thing, you're relying on all sorts of ordering and lifecycle processing that is not likely to be true going forward (see DynaFaces, for example). You can do a few things: - Create a parent component whose role in processing is to perform cross-component validations. - Use a phase listener and validation processing entirely external to the JSF component tree - Perform validation while committing (e.g., during the Invoke Application phase and an action) I kinda like the first one. What I'd really like to see is bean-level annotations describing validations that need to be run at that level (so, including cross-property validations), combined with the use of ELResolver/PropertyResolver magic to pick up on those bean-level validations (perhaps looking for bean-level annotations whenever a setValue() call is made). -- Adam On 10/16/06, Martin Marinschek wrote: > I totally agree, Matthias. But the question remains - how do you add a > validation framework if not via adding a validator with the normal > properties? > > And how will this framework be called in the case of a null value, if > JSF doesn't let the validators (of this extended framework) run? > > regards, > > Martin > > On 10/15/06, Matthias Wessendorf wrote: > > for the required case I agree > > > > general no. we (jsf) should not invent the wheel of validation at all. > > it is pretty much common so that is should be handled in 303. > > > > I agree that some *cross value* validations can be handy. sometimes yeah, > > sometimes no. a framework (see sf.net) on top of faces is maybe fine for that. > > > > what's in swing for the case "if field xyz is not submitted handle me like..." ? > > or is it only in 296 ? > > > > -M > > > > On 10/14/06, Martin Marinschek wrote: > > > Hi *; > > > > > > I've added a comment to > > > > > > http://issues.apache.org/jira/browse/MYFACES-1467 > > > > > > essentially saying that the null-value should never make a component > > > skip validation. What do you think about that? > > > > > > regards, > > > > > > Martin > > > > > > On 10/14/06, Matthias Wessendorf wrote: > > > > hey > > > > > > > > I created ADFFACES-238 to keep track of it and we should have issues > > > > in jira for almost all commits. > > > > > > > > Since you agreed to this issue, I commit the change to the template > > > > tomorrow or so > > > > > > > > On 10/13/06, Arjuna Wijeyekoon wrote: > > > > > I think you're right. > > > > > I could have sworn that we were special-casing the required-validator; I > > > > > even looked at the code in the old > > > > > corporate repository, but this bug exists there. > > > > > --arjuna > > > > > > > > > > > > > > > On 10/13/06, Matthias Wessendorf wrote: > > > > > > > > > > > > Hi > > > > > > > > > > > > please take a look at MYFACES-1467 which is also trure for > > > > > > UIXEditableValue.java's validate() method. > > > > > > > > > > > > But the spec javadoc for validate() says: > > > > > > Retrieve the submitted value with getSubmittedValue(). If this returns > > > > > > null, exit without further processing. (This indicates that no value > > > > > > was submitted for this component.) > > > > > > > > > > > > the patch is basicly doing this instead: > > > > > > > > > > > > Object submittedValue = getSubmittedValue(); > > > > > > if (submittedValue == null && !this.isRequired()) return; > > > > > > > > > > > > (it add's the && !this.isRequired()) > > > > > > > > > > > > > > > > > > Why? > > > > > > See the descr. for the issue, since a man-in-the-middle tool can do > > > > > > some funny things. I saw David's demo this afternoon in ApacheCon > > > > > > Hackaton. > > > > > > > > > > > > I think the javadoc for jsf 1.1 and 1.2 should be changed... > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -Matt > > > > > > -- > > > > > > Matthias Wessendorf > > > > > > http://tinyurl.com/fmywh > > > > > > > > > > > > further stuff: > > > > > > blog: http://jroller.com/page/mwessendorf > > > > > > mail: mwessendorf-at-gmail-dot-com > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > http://tinyurl.com/fmywh > > > > > > > > further stuff: > > > > blog: http://jroller.com/page/mwessendorf > > > > mail: mwessendorf-at-gmail-dot-com > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > > > > -- > > Matthias Wessendorf > > http://tinyurl.com/fmywh > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >