You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Martin Marinschek <ma...@gmail.com> on 2007/05/04 05:04:57 UTC
Re: tr:subform and autoSubmit bug
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);
}
doesn't that refer to what phase the event is being queued for?
regards,
Martin
On 4/26/07, Adam Winer <aw...@gmail.com> wrote:
> On 4/25/07, Martin Marinschek <ma...@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 <aw...@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...@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
Re: tr:subform and autoSubmit bug
Posted by Martin Marinschek <ma...@gmail.com>.
Sounds good!
regards,
Martin
On 5/5/07, Adam Winer <aw...@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 <aw...@gmail.com> wrote:
> > On 5/3/07, Martin Marinschek <ma...@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 <aw...@gmail.com> wrote:
> > > > On 4/25/07, Martin Marinschek <ma...@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 <aw...@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...@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
Re: tr:subform and autoSubmit bug
Posted by Adam Winer <aw...@gmail.com>.
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 <aw...@gmail.com> wrote:
> On 5/3/07, Martin Marinschek <ma...@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 <aw...@gmail.com> wrote:
> > > On 4/25/07, Martin Marinschek <ma...@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 <aw...@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...@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
> >
>
Re: tr:subform and autoSubmit bug
Posted by Adam Winer <aw...@gmail.com>.
On 5/3/07, Martin Marinschek <ma...@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 <aw...@gmail.com> wrote:
> > On 4/25/07, Martin Marinschek <ma...@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 <aw...@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...@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
>