Sounds good! regards,
Martin On 5/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> wrote: > On 5/3/07, Martin Marinschek <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > On 4/25/07, Martin Marinschek <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: > > > > > > > > > > > > <tr:inputText label="Your name" id="input1" value="#{helloWorldBacking.name}" > > > > > > 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 > > >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
