incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: tr:subform and autoSubmit bug
Date Mon, 07 May 2007 19:28:43 GMT
Sounds good!

regards,

Martin

On 5/5/07, Adam Winer <awiner@gmail.com> 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 <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
> > >
> >
>


-- 

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