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
