[
https://issues.apache.org/jira/browse/MYFACES-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754875#action_12754875
]
Werner Punz edited comment on MYFACES-2350 at 9/14/09 1:58 AM:
---------------------------------------------------------------
Ok we are dealing with several issues here:
first, the onClick event, what we have to do here is probably to use
jsf.util.chain to chain the old handler and our generated ajax script
onChange, etc... nothing has to be done here for f:ajax alone, but this is a
huge spec gap in m opinion on how to react to existing handlers,
To detect if we have an event collision can be done via the hints provided by
the behavior via getHints.
Submittting definitely means it has to be an onClick event in case of a
commandLink, then we can check of onClick has
a collision and we have to use jsf.util.chain to chain both events on javascipt
level probably providing an embedding function to jsf.util.chain
according to the spec I am right with my assumption here the spec states
that user and server side eventing scripts must be chained via jsf.util.chain
in following order:
first user specified event handlers,
secondly client behavior event handlers
third render specific event handlers.
Which means in case of our button
first the user onClick
secondly what is given back by the renderScripts function,
third the onSubmit code issued by the renderer!
all of that probably within the scope of anonymous functions aka
<script type="text/javascript">
jsf.util.chain(document.getElementById("buttonId"), "onClick", function()
{return userHandler}, function {return behaviorScript}, function() {return
rendererScript})
Note that if you look at the original jdocs of the spec or the
implementations, it is stated the functions are optional varargs which do now
manifest itself in the jsdocs but they are there,
Third we have to deal with parameters as such:
<h:commandLink id="button1" value="Press the Button"
action="#{backingBean.action}">
<f:param name="param1" value="value1"/>
</h:commandLink>
That one is easy, you just have to proved the needed postback parameters in the
BehaviorContext in the paramters Map being passed down to the renderScripts
method of the clientSide behavior object.
The spec states that exactly this data structure is there for adding parameters
which then can be posted!
On the client side in the jsf.ajax.request api we have something similar,
jsf.ajax.request(executes, renders, options), there the options list is a list
of postback parameters which can be set by the user, while the executes and
renders are datastrctures which map to predefined syntax.
The options basically is a javascript map with key values pairs which then care
pushed into the ajax request!
So utilizing the ClientBehaviorContext parameters on the javaside and the
options map on the javascript side is the way to go here!
was (Author: werpu):
Ok we are dealing with several issues here:
first, the onClick event, what we have to do here is probably to use
jsf.util.chain to chain the old handler and our generated ajax script
onChange, etc... nothing has to be done here for f:ajax alone, but this is a
huge spec gap in m opinion on how to react to existing handlers,
To detect if we have an event collision can be done via the hints provided by
the behavior via getHints.
Submittting definitely means it has to be an onClick event in case of a
commandLink, then we can check of onClick has
a collision and we have to use jsf.util.chain to chain both events on javascipt
level probably providing an embedding function to jsf.util.chain
Third we have to deal with parameters as such:
<h:commandLink id="button1" value="Press the Button"
action="#{backingBean.action}">
<f:param name="param1" value="value1"/>
</h:commandLink>
That one is easy, you just have to proved the needed postback parameters in the
BehaviorContext in the paramters Map being passed down to the renderScripts
method of the clientSide behavior object.
The spec states that exactly this data structure is there for adding parameters
which then can be posted!
On the client side in the jsf.ajax.request api we have something similar,
jsf.ajax.request(executes, renders, options), there the options list is a list
of postback parameters which can be set by the user, while the executes and
renders are datastrctures which map to predefined syntax.
The options basically is a javascript map with key values pairs which then care
pushed into the ajax request!
So utilizing the ClientBehaviorContext parameters on the javaside and the
options map on the javascript side is the way to go here!
> All renderers of components that implements ClientBehaviorHolder should
> encode javascript attributes
> ----------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2350
> URL: https://issues.apache.org/jira/browse/MYFACES-2350
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
>
> All components in javax.faces.component package implements
> ClientBehaviorHolder, and has properties used to render javascript.
> Right now, f:ajax tag handler implementation attach AjaxBehavior instances,
> but it is responsibility of the renderer to retrieve it and render it
> properly.
> This part is necessary to make f:ajax tag handler work (because this part
> shows the results!)
> There are two properties that needs special attention, because it collision
> with properties:
> clientEvent property html
> javascript in
> -------------------------------------------------------------------------------------------------------------
> valueChange valueChangeListener onchange
> UIInput
> action actionExpression onclick
> UICommand
> The interfaces _ChangeSelectProperties, _EventProperties,
> _FocusBlurProperties define javascript properties. Also, the class _HtmlBody
> has onload and onunload.
> We need to change all renderers to deal with this, taking into account the
> previous information.
> Also, it is necessary to add a call to Behavior.broadcast in
> UIComponentBase.broadcast, as described on its javadoc
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
