[
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:50 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
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,
what I propose would be following, and implementation extension, which deals
with this case
aka:
attachPoints (with a list of allowed attach points for the client behavior), I
also will file a bug report on the issue tracker of the spec to better deal
with this.
I assume the RI does a direct check via instanceof on component base to attach
the behavior to the components having some kind of attach point hinting system
seems the better way to go. (As I said, I assume, only here!!!)
Castin is a viable option for now since the only client behavior currently
delivered is the f:ajax, but nevertheless we need a better attach mechanism.
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.
