myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Werner Punz (JIRA)" <...@myfaces.apache.org>
Subject [jira] Issue Comment Edited: (MYFACES-2350) All renderers of components that implements ClientBehaviorHolder should encode javascript attributes
Date Mon, 14 Sep 2009 09:20:57 GMT

    [ 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 2:20 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

        <input type = "button" id = "chaincall" value = "press for chaintest"
               onclick = "jsf.util.chain(this, event, chaincall_userHandler, chaincall _behaviorHandler,
chaincall_scriptHandler);" />

with userHandler being

var chaincall_userHandler = function(event) {
   <userCode>;   
}
var chaincall_behaviorHandler = function(event) {
   <output of behavior getScripts> 
}
var chaincall_scriptHandler = function(event) {
   <whatever the script has to provide>
}

with chaincall_<functionName> on javascript level being a mapped (: is forbidden so
a mapping to _ should occur) clientId of the original components id!


Note that the user code does not have to return anything, in case of returning false
the subsequent subchain is interrupted, in case of true or null/undefined (no return value)
the subsequent chain elements are processed.
So there is no further need for embedding the code.


Also: 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

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!






  
> 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.


Mime
View raw message