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