[jsr-314-open-mirror] [jsr-314-open] status of <composite:clientBehavior> (was Re: "for" attribute for <f:ajax>)

Alexander Smirnov asmirnov at exadel.com
Tue May 4 19:00:59 EDT 2010


I guess what it is my fault because I've created the implementation but
not checked whether it is documented.
I recall the code and can describe tag attributes:
1) "event", type String. this is the name of target component event for
which behavior object will be attached.
2) "name", type String - the name of composite component behavior.
3) "default", type boolean, defines default composite component event,
same as the "action" is default for commandLink. There should be only
one default behavior per composite, exception will be thrown.
4) "targets" - the same as for all other <composite:... > tags.

On 05/03/2010 01:57 PM, Leonardo Uribe wrote:
> 
> 
> 2010/5/3 David Geary <clarity.training at gmail.com
> <mailto:clarity.training at gmail.com>>
> 
> 
> 
>     2010/5/3 Leonardo Uribe <lu4242 at gmail.com <mailto:lu4242 at gmail.com>>
> 
>         Hi
> 
> 
>         In myfaces we don't have <composite:clientBehavior> tag. The
>         reason is that we don't know which attributes this tag has, how
>         it looks like or where there is some example.
> 
> 
>     I am working on an article for ibm devworks where I give an example
>     of <composite:clientBehavior> -- I can send you the article if you
>     want, let me know. 
> 
> 
> Yes, I would like to have this article, it will help a lot. If you have
> time, please send it to my mail. Thanks for your help.
>  
> 
>     Anyway, here’s the core of my example. First, an icon composite
>     component:
> 
>     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> 
>             "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> 
> 
>     <html xmlns="http://www.w3.org/1999/xhtml"
> 
>         xmlns:h="http://java.sun.com/jsf/html"
> 
>         xmlns:f="http://java.sun.com/jsf/core"
> 
>         xmlns:composite="http://java.sun.com/jsf/composite">
> 
>         
> 
>         <composite:interface>
> 
>           <composite:attribute name="image" required="true"/>
> 
> 
>        
>       <composite:actionSource name="link" targets="#{clientId}:iconForm:link"/>
> 
>                                      
> 
>        
>       <composite:clientBehavior name="click" targets="#{clientId}:iconForm:link"
> 
>                                    event="action"/>                    
>            
> 
>         </composite:interface>
> 
> 
>         <composite:implementation>
> 
>           <div id="#{cc.clientId}">
> 
>           
> 
>            <h:form id="iconForm">
> 
>           <h:commandLink id="link" immediate="true">
> 
>             <h:graphicImage value="#{cc.attrs.image}"/>
> 
>           </h:commandLink>
> 
>           </h:form>
> 
>         
> 
>         </div>
> 
>         </composite:implementation>    
> 
>     </html>
> 
> 
>     The <composite:clientBehavior> tag specifies the name of the event
>     (click), the target(s) for the event (#{clientId}:iconForm:link),
>     and the component event (action). 
> 
>     The preceding markup is in resources/util/icon.xhtml, so you use an
>     icon like this:
> 
>             <util:icon id="minus" image="#{resource['images:minus.gif']}">
> 
>               <f:ajax event="click" render=":readout :fontPreview"/>
> 
>            
>       <f:actionListener for="link" type="com.clarity.DiskIconListener"/>
> 
>             </util:icon>
> 
> 
>     For the click event in the icon, JSF makes an Ajax call to the
>     server, and when the call returns, it renders readout and
>     fontPreview components. The click event is associated with the
>     action event of the target (the link). So, when an action event
>     occurs in the link, JSF send an Ajax call to the server.
>      
> 
>         In theory it works like <composite:actionSource>,
>         <composite:valueHolder>, <composite:editableValueHolder>.
> 
>         I pointed this issue multiple times (really a lot of times but
>         it seems nobody took that seriously). Just take a look at: 
> 
> 
>         http://markmail.org/message/dxlpoa3qgul7uuns?q=composite:clientBehavior
> 
>         As soon as any documentation is available on mojarra javadoc
>         I'll do the necessary stuff on myfaces.
> 
> 
>     This really needs to be addressed asap, so the feature does not
>     become Mojarra-dependent, which greatly limits its usefulness.
>     Besides the javadoc, it needs to be mentioned in the spec.
> 
>     I think whoever documented the composite library should come forward
>     and update the PDL docs and spec. And if Ed won’t do it, I might
>     help out. :)
> 
> 
>     david
> 
> 
> 
>         regards,
> 
>         Leonardo Uribe
> 
>         2010/5/3 David Geary <clarity.training at gmail.com
>         <mailto:clarity.training at gmail.com>>
> 
>             Thanks, Roger!
> 
> 
>             david
> 
>             2010/5/3 Roger Kitain <roger.kitain at oracle.com
>             <mailto:roger.kitain at oracle.com>>
> 
>                 I think this was an oversight since this was one of the
>                 last remaining spec areas that went in.
>                 I will file a spec issue on this.
>                 Thanks for catching it.
> 
>                 -roger
> 
> 
>                 On 5/3/10 2:31 PM, David Geary wrote:
>>                 There is a <composite:clientBehavior> tag in the 2.0
>>                 version of JSF that comes with GlassFish, and it
>>                 appears to work as advertised by Alexandr and Andy below.
>>
>>                 But, as Alexandr points out, it’s not documented in
>>                 the PDL docs, nor could I find any mention of it in
>>                 the spec (or Ed’s book, either).
>>
>>                 This is a vital tag that lets page authors attach ajax
>>                 functionality to components within composite
>>                 components. I see no reason why it should not be
>>                 documented.
>>
>>                 Does anyone know why this tag was not documented in
>>                 the first place, or what the plans are for its future?
>>                 Anyone know if it works with MyFaces 2.0?
>>
>>                 If there’s not a compelling reason for blacklisting it
>>                 from the docs, can we document it?
>>
>>                 Thanks,
>>
>>
>>                 david
>>
>>
>>
>>                 2009/5/26 Alexandr Smirnov <asmirnov at exadel.com
>>                 <mailto:asmirnov at exadel.com>>
>>
>>                     Sure, the composite client event tags are not
>>                     included in the PDL doc.
>>                     There is one            <composite:clientBehavior>
>>                     tag with attributes: 'name' -
>>                     the virtual event name that composite component has.
>>                     'default' "true/false" defines the default event
>>                     that is enclosed
>>                     <f:ajax> tag serves if 'event' attribute was omited.
>>                     'event' - the real event name for target component.
>>                     'targets' - space-delimited list of component id's
>>                     for which composite
>>                     component behavior or <f:ajax> tag will be redirected.
>>
>>                     The model with 'for' attribute was the first
>>                     implementation but it was
>>                     replaced wit 'virtual' event model.
>>
>>                     Andy Schwartz wrote:
>>                     > David -
>>                     >
>>                     > David Geary wrote On 5/24/2009 5:55 PM ET:
>>                     >> For JSF 2, we added a "for" attribute to
>>                     f:actionListener,
>>                     >> f:converter, etc., but we don't have a "for"
>>                     attribute for <f:ajax>.
>>                     >> AFAICT, that means that although you can attach
>>                     listeners, validators,
>>                     >> converters, etc. to a component contained in a
>>                     composite component,
>>                     >> you cannot attach Ajax functionality.
>>                     >>
>>                     >> Why is that? Is it an oversight, or is there
>>                     some compelling technical
>>                     >> reason to disallow adding Ajax behavior to
>>                     components contained in
>>                     >> composites?
>>                     >
>>                     > We definitely intended to support this, though
>>                     instead of exposing a
>>                     > "for" attribute on <f:ajax>, we wanted to
>>                     leverage the fact that
>>                     > behaviors already have a targeting mechanism in
>>                     the "event" name.  The
>>                     > idea was that a composite component would, like
>>                     any other
>>                     > ClientBehaviorHolder, expose a set of logical
>>                     event names that behaviors
>>                     > can be attached to.  So, for example, assuming a
>>                     composite component
>>                     > included "OK" and "Cancel" buttons and wanted to
>>                     allow the user to
>>                     > attach action behaviors to these, the composite
>>                     component might surface
>>                     > "okAction" and "cancelAction" event names,
>>                     allowing the page author to do:
>>                     >
>>                     >  <foo:someComposite>
>>                     >    <f:ajax event="okAction"/>
>>                     >    <f:ajax event="cancelAction"/>
>>                     >  </foo:someComposite>
>>                     >
>>                     > I know that Alexander did the implementation
>>                     work to get this up and
>>                     > running.  However, I do not see any pdldoc for
>>                     the composite tag that
>>                     > the composite component author uses to specify
>>                     the supported client
>>                     > behavior event names (composite:clientBehavior I
>>                     believe).
>>                     >
>>                     > Alex, Roger -
>>                     >
>>                     > Did this make it into 2.0?
>>                     >
>>                     > Andy
>>                     >
>>                     >>
>>                     >> Thanks,
>>                     >>
>>                     >>
>>                     >> david
>>
>>
> 
> 
>                 -- 
>                 roger.kitain at oracle.com <mailto:roger.kitain at oracle.com>
>                 https://twitter.com/rogerk09
>                 http://www.java.net/blogs/rogerk  
> 
> 
> 
> 
> 
> 



More information about the jsr-314-open-mirror mailing list