incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: tr:subform and autoSubmit bug
Date Fri, 04 May 2007 22:01:37 GMT
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 <awiner@gmail.com> wrote:
> On 5/3/07, Martin Marinschek <martin.marinschek@gmail.com> 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 <awiner@gmail.com> wrote:
> > > On 4/25/07, Martin Marinschek <martin.marinschek@gmail.com> 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 <awiner@gmail.com> 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 <my_trash_mail@yahoo.com> 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
> >
>

Mime
View raw message