Basic UICommand ActionEvent question

[lightbulb432 <ve...@hotmail.com>]

The following is from a JSF resource:

"If the user triggered the request by clicking a button or a link, the
corresponding UICommand component discovers this in the Apply Request Values
phase when it finds a request parameter with a name that matches its ID. It
creates an ActionEvent to represent the event, but doesn't notify the
listeners immediately, because the rest of the components in the tree may
not have picked up their values yet. Instead it adds it to a queue by
calling its queueEvent() method."

What confuses me is how if you have a page A that contains a command link to
a page B, when page B's component tree is created, how will that command
link ever find a request parameter "with a name that matches its
ID"...doesn't the command link exist only in page A, not in page B? (Is the
paragraph above describing only what happens when page A forwards to itself,
page A?)

This is actually part of a bigger issue I'm having trouble with: anytime you
have a page that is the result of a request, wouldn't the component tree in
that second page have different components from that in the page that
initiates the request, making all of these issues (conversion, validation,
and the other JSF phases) not possible to do - because the components have
never existed prior to this page. It seems all these things only happen when
a page forwards to itself (page A to page A), but what about page A to page
B types of scenarios?

But clearly that's not how it works, and I know I'm completely thinking
about this the wrong way...perhaps somebody here could clear things up.
Thanks.
-- 
View this message in context: http://www.nabble.com/Basic-UICommand-ActionEvent-question-tf2792395.html#a7790584
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Basic UICommand ActionEvent question

[Simon Kitching <si...@rhe.co.nz>]

lightbulb432 wrote:
> The following is from a JSF resource:
> 
> "If the user triggered the request by clicking a button or a link, the
> corresponding UICommand component discovers this in the Apply Request Values
> phase when it finds a request parameter with a name that matches its ID. It
> creates an ActionEvent to represent the event, but doesn't notify the
> listeners immediately, because the rest of the components in the tree may
> not have picked up their values yet. Instead it adds it to a queue by
> calling its queueEvent() method."
> 
> What confuses me is how if you have a page A that contains a command link to
> a page B, when page B's component tree is created, how will that command
> link ever find a request parameter "with a name that matches its
> ID"...doesn't the command link exist only in page A, not in page B? (Is the
> paragraph above describing only what happens when page A forwards to itself,
> page A?)

A command link on page A always posts back to the same "view" that was 
used to render A. The "component tree" for view A is restored, Apply 
Request values is executed on it, etc. As described, the clicked-on 
command component will queue an event. Eventually, the Invoke 
Application phase is reached, and so the queued event is executed; this 
triggers a call to the action method associated with the command link, 
and the string returned by that method is used for "navigation" 
(presumably to view B). If the action is a literal string, then that is 
used directly.

The JSF framework *then* creates a new component tree for view B, and 
leaps to the RENDER phase; there is no "Apply Request Values" run on 
this component tree; this would be pointless.

In the case where a commandButton has immediate=false, this is all very 
sensible; immediate=false means that you do want to push input data in 
the submitted form into the model before going to view B, and that you 
don't want to go to page B if validation fails.

When immediate=true set, this is a little inefficient, as the 
restore-view and Apply Request Values phases get run even though the 
results then get discarded because the page immediately navigates to 
view B without pushing data into the model. However it's not a big deal.

> 
> This is actually part of a bigger issue I'm having trouble with: anytime you
> have a page that is the result of a request, wouldn't the component tree in
> that second page have different components from that in the page that
> initiates the request, making all of these issues (conversion, validation,
> and the other JSF phases) not possible to do - because the components have
> never existed prior to this page. It seems all these things only happen when
> a page forwards to itself (page A to page A), but what about page A to page
> B types of scenarios?
> 
> But clearly that's not how it works, and I know I'm completely thinking
> about this the wrong way...perhaps somebody here could clear things up.
> Thanks.

I think the info above also answers this..

Regards,

Simon