[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_12534004 ] 

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

Sorry for taking so long to respond; a lot of work kept me.

First, I used server state saving in testing the proposed patch, so I did not run into the 2k limit.

Second, I was still a jsf greenhorn when proposing this patch. At that time, I was not aware how much limitations a non-javascript implementations would have. So maybe it is better to leave the standard commandLink component as it is and fail cleanly without javascript. The users willing to accepts the limitations of not using javascript could then use custom components.

The remaining problem with this approach is that the form does not allow its children to decode their state if the form is not submitted. I can see the reason behind this; if one has more than one form on a page, the components on the non-submitted form should keep their state. However, this kills any non-javascript approaches. Also, a submit for only one component in a form might be interesting for partial page rendering.

In my opinion, the cleanest approach would be if the form lets each component decide whether it should render itself or not. E.g. a text input field would check whether its associated html parameter is null or not; if it is null it would not decode itself. However, other components like BooleanSelectCheckbox would need to ask the form whether ist is submitted or not: a null value of the associated parameter could mean a) that the form is not submitted or b) that the form is submitted but the checkbox is not checked. 

The drawback in changing this behaviour is that it breaks the behaviour of custom components in a multi-form page: These components are not aware of that they should decide whether to decode themselves or not.

Do you think the "let the components decide whether to decode themselves"  approach has any chance of being incorporated into the standard faces distributions ? or are the compatibility problems too big ?


> 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.