[
https://issues.apache.org/jira/browse/MYFACES-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907920#action_12907920
]
Werner Punz edited comment on MYFACES-2458 at 9/10/10 4:16 AM:
---------------------------------------------------------------
Ok I just checked the f:ajax onError problem, I am not sure if this is really a
bug, because the way it is rendered...
you pass an unwrapped command as error handler which is executed automatically
at onclick time.
I will check mojarra if it also does it, but I think passing a simple alert as
error handler is a no go here, because at render level where it should be
interecepted it cannot be clearly determined whether the code is a function or
not (we are on java there)
wrapping it into a string might be a way to go and then wrapping the string
into a function and an eval.
I will investigate further but I assume mojarra also does it like we do and the
asumption on how to set the error handler simply is wrong, I will check it.
Ok I did a recheck on this one mojarra renders
mojarra.ab(this,event,'action',0,0,{'onerror':alert(1)});
Also the spec clearly states that onerror expects a event handler function:
quote spec: jsf.js jsdocs:
The set of available options that can be sent as request parameters to control
client and/or server side request processing. Acceptable name/value pair
options are:
name value
execute space seperated list of client identifiers
render space seperated list of client identifiers
onevent function to callback for event
onerror function to callback for error
params object containing parameters to include in the re
The format of the callback function is defined as is:
jsf.ajax.addOnError(handleError);
...
var handleError = function handleError(data) {
...
}
So I assume we can reclose this issue now
was (Author: werpu):
Ok I just checked the f:ajax onError problem, I am not sure if this is
really a bug, because the way it is rendered...
you pass an unwrapped command as error handler which is executed automatically
at onclick time.
I will check mojarra if it also does it, but I think passing a simple alert as
error handler is a no go here, because at render level where it should be
interecepted it cannot be clearly determined whether the code is a function or
not (we are on java there)
wrapping it into a string might be a way to go and then wrapping the string
into a function and an eval.
I will investigate further but I assume mojarra also does it like we do and the
asumption on how to set the error handler simply is wrong, I will check it.
Ok I did a recheck on this one mojarra renders
mojarra.ab(this,event,'action',0,0,{'onerror':alert(1)});
which means it does the same, I do not really see the problem hence as bug, but
more along the lines of a user error.
> Miscellaneous AJAX bugs
> -----------------------
>
> Key: MYFACES-2458
> URL: https://issues.apache.org/jira/browse/MYFACES-2458
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-alpha-2
> Reporter: Curtiss Howard
> Priority: Minor
> Fix For: 2.0.2-SNAPSHOT
>
>
> There are a couple minor AJAX-related bugs:
> * h:commandButton needs to append "return false;" for onclick when a behavior
> chain is present.
> * if <f:ajax> disabled=true, the AJAX call is still emitted.
> * Possible issue with <f:ajax> execute="multiple ids". Seems the
> javax.faces.partial.execute request param may differ from Sun RI.
> * Unable to restore StateHolder when listener is specified for <f:ajax>.
> * <f:ajax> onevent not being handled.
> * <f:ajax> onerror not being handled.
> * <f:ajax> render="@all" not working correctly.
> * <f:ajax> render="@form" not working correctly.
> * <f:ajax> render="@this" not working correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
