[jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?

Andy Schwartz andy.schwartz at oracle.com
Mon Aug 24 17:29:11 EDT 2009


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





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