[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584107#action_12584107
]
Simon Kitching commented on MYFACES-1692:
-----------------------------------------
I think this issue should remain open, but changed from bug to enhancement.
Using "real" links where javascript is supported seems nicer. However when it
is disabled (ie ALLOW_JAVASCRIPT=false) it would be nice for h:commandLink to
automatically switch to rendering a button rather than just be broken.
However the implementation does require a little more thought; defining the
style directly on the button is most convenient but makes it hard for users to
override the style (I think direct styles have higher priority than almost any
other css rule?). Adding a style-class is better, but myfaces would then need
to ensure that the rule was defined; as css rules in HTML need to be defined in
the <head> section that becomes a little tricky. Ecch.
Maybe support a config param "org.apache.myfaces.COMMAND_LINK_CLASS"? When set,
output that as the "class" for the button written by the commandLink renderer
(and the user is responsible for ensuring that a style exists for that class).
When the option is not set, hard-wire the style property with the default
styling.
> 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.
