From adffaces-user-return-2881-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Fri May 04 22:02:01 2007 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 75345 invoked from network); 4 May 2007 22:02:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 May 2007 22:02:00 -0000 Received: (qmail 81293 invoked by uid 500); 4 May 2007 22:02:06 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 81269 invoked by uid 500); 4 May 2007 22:02:06 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 81259 invoked by uid 99); 4 May 2007 22:02:06 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2007 15:02:06 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of awiner@gmail.com designates 64.233.162.238 as permitted sender) Received: from [64.233.162.238] (HELO nz-out-0506.google.com) (64.233.162.238) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2007 15:01:58 -0700 Received: by nz-out-0506.google.com with SMTP id j2so1046880nzf for ; Fri, 04 May 2007 15:01:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iokkEx/cJFY8wQn7EXQC/oRnyUcUOYtWNHbvAiBJ9mVl5lNcT3CmeckNVnJO+OYqK4QwPGqag1wtIfjb/j4DV5PsEojffyVNp9/fMXuoJfEpc6xhcIdz7geye87iyephNfxwRQ2VCYEGvMIn11ILG9LBAETm38pI+i7HX5SRrXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mobnAPoEO+1/5sYnFq5CRS5bWXffYvMDjW/p7CzfkN8LPpwEOxJWLJ44vL/fxWOPHM6NQ6DaYkwzq87FZBQSyo4tnoi0kDJ8uaaMKZy04JaQ5diBI0JsAzWIBCevoQke5rCnTEZnUHKI6mhV23rBc6LiWw+JoYR0nZnHRAfhMcw= Received: by 10.114.182.1 with SMTP id e1mr1289776waf.1178316097373; Fri, 04 May 2007 15:01:37 -0700 (PDT) Received: by 10.115.76.3 with HTTP; Fri, 4 May 2007 15:01:37 -0700 (PDT) Message-ID: <6dac79b90705041501p71600e2ex12b8cc5b35c5bd7e@mail.gmail.com> Date: Fri, 4 May 2007 15:01:37 -0700 From: "Adam Winer" To: adffaces-user@incubator.apache.org Subject: Re: tr:subform and autoSubmit bug In-Reply-To: <6dac79b90705040942j67e1f8f8i36d8bc53c663aecb@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: <759220.32424.qm@web32007.mail.mud.yahoo.com> <6dac79b90704241312h1e6a0dbboa981db6c91044954@mail.gmail.com> <5a99335f0704250522p64aab7car1858c5ea39be9291@mail.gmail.com> <6dac79b90704260952w69664159y39d2eedce3e851c3@mail.gmail.com> <5a99335f0705032204q6200492k77576a7af69bb169@mail.gmail.com> <6dac79b90705040942j67e1f8f8i36d8bc53c663aecb@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org OK, I've implemented this and filed and fixed: http://issues.apache.org/jira/browse/ADFFACES-485 A loooong standing bug now gone - thanks for pushing on this one! -- Adam On 5/4/07, Adam Winer wrote: > On 5/3/07, Martin Marinschek wrote: > > You're right - I actually hadn't thought about the fact that probably > > all events need to trigger the subform. For me, only action-events > > where relevant, but true, there is more to this. > > > > The rest of your mail I don't understand - see this source in UIXSubForm: > > > > // If the event is being queued for anything *after* APPLY_REQUEST_VALUES, > > // then this subform is active. > > if (PhaseId.APPLY_REQUEST_VALUES.compareTo(event.getPhaseId()) < 0) > > { > > _storeSomethingSubmitted(FacesContext.getCurrentInstance()); > > setSubmitted(true); > > } > > Wow, it's been a looong time since I've read my own code!!! > I'm glad you're paying attention. :) > > I can't think what the point of that PhaseId check is, to be > honest. I'm assuming I had a reason for writing it, but > most APPLY_REQUEST_VALUES events will end up > calling FacesContext.renderResponse(), making it moot. > > Anyway, the issue here is that ValueChangeEvents > from autoSubmit aren't queued to Process Validators. > But since nothing got queued during processDecodes(), > UIXSubform.processValidators() will block processValidators() > from running at all, so no Value Change Event gets queued. > > What I can come up with is to have autoSubmit > not just result in a blind submit, but to actually > send an event in the request parameters that > the Renderer detects. Then the Renderer queues > a dummy FacesEvent - some private subclass > that is: > - INVOKE_APPLICATION phase > - always returns false for "isAppropriateListener()" > This'd trigger the subforms into processing. It's > marginally more overhead for the renderers, but not > that much. I'll give this a whirl. > > -- Adam > > > > > > > On 4/26/07, Adam Winer wrote: > > > On 4/25/07, Martin Marinschek wrote: > > > > The problem is that the JSF spec allows wrapping a FacesEvent without > > > > providing access to the original event (by calling getCause() or > > > > something similar). > > > > > > > > If we had this ability, we could check for a type ActionEvent, so your > > > > workaround has been checking for the phase of the queued event, which > > > > is a hack at best. > > > > > > What workaround are you talking about? Subform doesn't > > > care about ActionEvent, etc. - all events are equal in its eyes. > > > It also doesn't care about the phase the queued event will be > > > delivered - it cares *what phase it got queued in*. > > > > > > -- Adam > > > > > > > > > > > > > > regards, > > > > > > > > Martin > > > > > > > > On 4/24/07, Adam Winer wrote: > > > > > It's a known limitation of how subforms are implemented: > > > > > they look for FacesEvents queued during processDecodes() > > > > > to see if that subtree should be further processed. However, > > > > > autoSubmit components don't queue a FacesEvent until > > > > > ValueChangeEvent, which happens later in the cycle. > > > > > > > > > > It should get fixed, though. > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > On 4/24/07, D. Cardon wrote: > > > > > > Hi, > > > > > > > > > > > > I've done some more testing with the subform functionality in Trinidad and > > > > > > think I've isolated a bug with a very simple test case. To reproduce this > > > > > > functionality, a few modifications need to be made to the blank project that is > > > > > > found in the trinidad repository. Here's what to do: > > > > > > > > > > > > - Modify the index.jspx entry for the tr:inputText, replacing it with: > > > > > > > > > > > > > > > > > autoSubmit="true" valueChangeListener="#{helloWorldBacking.changeMethod}" /> > > > > > > > > > > > > Then, implement the changeMethod in the backing bean: > > > > > > > > > > > > public void changeMethod( ValueChangeEvent event ) > > > > > > { > > > > > > System.out.println( "Change method called!" ); > > > > > > } > > > > > > > > > > > > Now, test the page by entering a value into the test field and then tabbing > > > > > > away from it. This will fire the field to be submitted. In your console, you > > > > > > should see the "Change method called!" message appearing--this behaves as > > > > > > expected. > > > > > > > > > > > > To reproduce the invalid behavior with a subform, alter index.jspx slightly, by > > > > > > wrapping the inputText (or its containing component) in a tr:subform tag. > > > > > > Reloading the page and performing the test again, you should no longer see the > > > > > > "Change method called!" message. This behavior appears to be the same for any > > > > > > component set to autoSubmit. > > > > > > > > > > > > After digging into the code somewhat, it appears that the subform is unaware > > > > > > that the inputText component has changed and so it does not run its children > > > > > > through the necessary phases. > > > > > > > > > > > > The root of this symptom actually relates to a lot of other problems with the > > > > > > subform tag. For example, using the subform to isolate regions for validation > > > > > > does not work at all due to this issue, because validations are not processed > > > > > > and model values are not updated for the components in the subform. > > > > > > > > > > > > Since I'm a new Trinidad user, I don't really know how this should be reported. > > > > > > I did sign up for JIRA, but I'm not sure what the severity of the issue should > > > > > > be. Also, it would be reassuring if someone else can reproduce this, that > > > > > > would verify that it's not just some problem with my machine / setup. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > --David > > > > > > > > > > > > __________________________________________________ > > > > > > Do You Yahoo!? > > > > > > Tired of spam? Yahoo! Mail has the best spam protection around > > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > http://www.irian.at > > > > > > > > Your JSF powerhouse - > > > > JSF Consulting, Development and > > > > Courses in English and German > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > >