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
>
