Hello team, Mojarra impl issue 1143 asserts there is a use case for which allowing the value of the "event" attribute of<f:ajax> (and thus for all behaviors) to be a ValueExpression, at least in the case of composite components. I suspect there's a good reason why we chose to force the value of the event attribute to be literal, likely security. However, I want to know why so I can close this bug in an informed manner, or challenge our decision and possibly broaden the allowable value type for the attribute. Can someone please enlighten me? Sincerely, Ed

Right. Behaviors are created and wired into the component tree during tag/handler execution. The event name is used during this process - ie. is specified when registering the Behavior with the hosting UIComponent. In theory we could allow the event name to be specified via an EL expression, but the spec would need to be clear that this EL expression would be evaluated immediately during tag/handler execution (as the component tree is built) rather than deferred/re-evaluated during later phases. So, yes, in many ways this is similar to f:facet's "name" attribute. Andy Alexander Smirnov wrote: > At least, the literal value would reduce a number of support requests > :-). A lot of people reported about 'rendered' attribute "issue", > there they have a different value of bean property which is bonded to > the 'rendered' attribute, therefore some components are not called > during execution phases. > To be serious, behavior works like GUI event handler on client and > server side, hence it has some component functionality and should be > attached to the same event during execute phase as it has been > rendered. The same thing is why 'facet' name could be literal only, I > guess. > > > On 08/21/2009 07:55 AM, Ed Burns wrote: > >> Hello team, >> >> Mojarra impl issue 1143 asserts there is a use case for which allowing >> the value of the "event" attribute of<f:ajax> (and thus for all >> behaviors) to be a ValueExpression, at least in the case of composite >> components. >> >> I suspect there's a good reason why we chose to force the value of the >> event attribute to be literal, likely security. However, I want to >> know >> why so I can close this bug in an informed manner, or challenge our >> decision and possibly broaden the allowable value type for the >> attribute. >> >> Can someone please enlighten me? >> >> Sincerely, >> >> Ed >> >>