[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584051#action_12584051
]
Simon Kitching commented on MYFACES-1692:
-----------------------------------------
(1)
Hmm..what exactly is the required behaviour of an h:commandLink? I had always
assumed (and myfaces has always implemented) it works just like
h:commandButton. Should check this.
But assuming that commandLink and commandButton should have the same behaviour
(just with different visual representation) then commandLink really *must*
submit the enclosing form. As Leonardo points out, without that any data that
the user enters into a form will be lost.
And I'm pretty sure there *is* no way to submit a form from a link without
script. Http was designed with the idea that a link and a form are two quite
different things; links do not vary depending on the state of other input
fields on the page.
However I had thought that a solution to this no-javascript issue had already
been implemented: for h:commandLink to render a button with a css style that
makes it look like a link. This certainly was being discussed - was it not
committed? I'm not 100% sure how this works for disabled users (eg
screen-readers for the blind) but initially it seems ok; a submit button should
be understandable. Probably better than a link that triggers javascript to
submit some not-obviously-related form.
(2)
To repeat an earlier comment: the view state can be of any size but a link has
a fixed limit on the size of its query parameters. So any kind of solution
implemented with links should just refuse to work with client-side state (throw
an exception). Otherwise, a page will work with N components, then suddenly
fail with N+1 components. That's really ugly.
Supporting server-side state is ok; the link just needs query params that
contain the "key" of the server-side state data.
(3)
I can imagine a new component, called "t:goLink" or some similar name. It could
do a postback and run action listeners. However it could never implement the
full expected behaviour of h:commandLink (see comment 1 above). Because of the
loss of user input, it is really useful only for cases where the action always
navigates to some other page (so should probably be hard-wired with
immediate=true).
And it would only work reliably with server-side state (see comment 2 above).
(4)
Yes, if h:commandLink is used but the browser is known to not support
javascript then some kind of warning or error would probably be a good idea.
However I'm not sure that this can be reliably detected on the server. Can
JavascriptUtils.isJavascriptAllowed really work? Maybe instead h:form could
check whether any component has output javascript into the page, and if so then
render a <noscript> tag containing a warning message? Certainly IE and Firefox
will render a noscript block iff javascript is disabled for that page..
> 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.
