[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed

["Thomas Fischer (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516738 ] 

Thomas Fischer commented on MYFACES-1692:
-----------------------------------------

I created a fix for the problem by appending the correct parameter to the link. In HtmlLinkRendererBase Rev 544646, I added the following after line 401 (sorry for not being able to produce a diff, I'm still trying to understand the myfaces build process):

hrefBuf.append('&');
hrefBuf.append(ResponseStateManager.VIEW_STATE_PARAM);
hrefBuf.append('=');
hrefBuf.append(
    StateUtils.construct(
        new Object[] {null, null, facesContext.getViewRoot().getId()}, 
        facesContext.getExternalContext()));

I'm rather sure this is just a hack and not a real solution, as I am not familiar with the myfaces internals, but maybe it can serve as a start.
After applying the patch, Myfaces recognized the request as a postback but the problem remained. After some more debugging it turned out that the problem now was that the commandLink was wrapped in  a form. On decoding the form (UIForm.processDecodes()), the following code line is encountered before the form decodes its children:

if (!isSubmitted()) return;

As the form is not submitted (because a link is not a form submit), the children of the form are not decoded. I do not think that this is the correct behaviour, as this prevents all components that happen to be wrapped in the form tag from being decoded, even if they have nothing else to do with the form. After commenting out the above line of code, the problem was solved. NB: the same line of code exists in UIForm.processValidators() and UIForm.processUpdates(), I'm not sure whether it should be there.

> CommandLink does not execute action if no javascript is allowed
> ---------------------------------------------------------------
>
>                 Key: MYFACES-1692
>                 URL: https://issues.apache.org/jira/browse/MYFACES-1692
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions:  1.2.0
>         Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server, org.apache.myfaces.ALLOW_JAVASCRIPT=false
>            Reporter: Thomas Fischer
>
> Situation:
> The tag <h:commandLink action="#{someBean.someAction}" value="submit"></h:commandLink> is used in a jsp page, which is visited by the user. The user clicks on the link.
> Expected behaviour:
> The method someBean.someAction() should be called, and the navigation rule which matches the outcome should determine the page to be displayed.
> Wrong behaviour:
> The method defined in action is not called and the same jsp page is rendered again. 
> I did some debugging to find the reason of this problem. It seems to me that the server does not recognize that the click on the link is a postback. In line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for existence. If it is there, the request is a callback, and if it is not there, the request is not treated as postback. This parameter is not encoded in the link rendered by h:commandLink, thus the request is not treated as a postback, and the page is just rendered again.
> If javaScript rendering is allowed, this works fine because the HTTP parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input field, and the javascript code does a form submit.
> It seems to me that the problem could be solved by adding the parameter ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not check it).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.