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
