linking from one page to another with same parameter names - a sequence of events with undesirable outcome

[M Rather <mr...@definedlogic.com>]

Hello,

I ran into an issue, which I would like to share here. I would like to 
know, if it is something that I have done incorrectly (due to not fully 
understanding JSF lifecycle), or is it something that may be an issue 
with how JSF lifecyle works.

Here is a scenario:

I have a page : customerList.xhtml
It lists customers, and for each row of a customer there is a link 
(commandLink) to root nodes of menu's for the customer.
Accordingly, there is a navigation rule from customersList.xhtml with 
action 'menus' that takes users to rootMenuList.xhtml with parameter 
'customerId'.
Please note the parameters sent in this and following, as that is 
important to discussion.

When a user clicks that link, system goes thru its lifecycle (i.e. 
restores customerList.xhtml and then in BEFORE INVOKE_APPLICATION(5)
phase recognizes 'menus' outcome and builds 'rootMenuList.xhtml' view 
and forwards the user there.


All ok till here.

rootMenuList.xhtml loads all the root nodes for that provided customer 
and draws a list of root menu nodes.
Each row of the this list is a commandLink to 'menusList.xhtml' with 
action 'menu' with pameters 'customerId' and 'menuId'

When a user clicks that link, system goes thru its lifecycle (i.e. 
restores rootMenuList.xhtml and then in BEFORE INVOKE_APPLICATION(5)
phase recognizes 'menu' outcome and builds 'menuList.xhtml' view an 
forwards the user there.

All ok till here also.


menuList.xhtml loads all the nodes for the provided menuId and draws a 
list of menu nodes, INCLUDING the root menu node itself.
Each row of this list is a commandlink to 'contentList.xhtml' with 
action 'contents' with parameters 'customerId' and 'menuId'

Note: That is the only information that is needed to draw contents so I 
just send 'customerId' and 'menuId'

This is where the following behavior occurs:
-------------------------------------------

When a user clicks the 'first' (the root node) link on the list, system 
goes thru its lifecyle (i.e. restores menuList.xhtml and then in BEFORE 
INVOKE_APPLICATION(5)
phase recognizes 'contents' outcome and builds 'contentList.xhtml' view 
and forwards the user there.

This row click works OK.

But, if a user clicks on 'any' other link with action 'contents' of the 
list, i.e. , any other node of this list, then system goes thru its 
lifecycle , restores the view,
BUT, in INVOKE_APPLICATION(5) it does 'NOT' recognize any outcome, and 
redraws 'menusList.xhtml' with the provided menuId, instead of
drawing 'contentList.xhtml' as requested.

I hope this is clear.

Now , how did I resolve this, for all those who have encountered similar 
issues.

I added a third parameter 'contentMenuId' for the commandLink for 
'contentList.xhtml', now totaling the following links:
'customerId', carried forward from first page till here.
'menuId', menuId of the rootMenu (still needed to restore the 
'menuList.xhtml' before drawing 'contentList.xhtml')
'contentMenuId', menuId of the current row in 'menuList.xhtml'.
(so, for the first row, 'menuId' and 'contentMenuId' is same)

This solves the problem.

Now the question, and one of the reasons I am sharing this.

Without the workaround, when a user clicks any other row of menuId, why 
does JSF lifecycle decide to draw the page instead of follow the 
'outcome' in action?
 From the logs of the first and secondary clicks, I do see that JSF 
recognizes it is a postback. But it still thinks that it needs to redraw 
the page for newId?
Where does JSF figure out that the menuId submitted is different from 
the first one, so there is no need to follow the 'action' and 'outcome' 
of 'commandLink' ?
Should not JSF logs identify this anywhere?

Thanks for those who read it, and those who may want to respond.

-MRather