[jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut

Alexander Smirnov asmirnov at exadel.com
Mon Oct 5 14:45:53 EDT 2009



On 10/05/2009 11:07 AM, Ted Goddard wrote:
>
> On 2009-10-02, at 2:23 PM, Ed Burns wrote:
>
>> OPTION ELEvaluatedInCSSOnly
>>
>> With this option, we modify Resource.getInputStream() to state that EL
>> evaluation in CSS files is enabled by default. We will state that care
>> must be taken by the user to ensure that the EL expression always
>> evaluates to the same thing across multiple requests. We will state
>> that the user may decorate the ResourceHandler to get more flexibility.
>>
>> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>
> +1
I prefer to not modify Resource object but move that functionality to 
CSS renderer. Suppose you are develop an ResourceHandler extension that 
uses SQL database or LDAP as resource storage. If el evaluation is part 
of Resource.getInputStream(), you have to implement not only storage 
access but dependent of content el evaluation also. In the case of 
Renderer, it would be pretty simple because all content-dependent action 
will be separate from storage access.
>
> Confining this evaluation to CSS would appear to lower the risk.
> I would like to see the explanation for why relative paths do not
> work for classpath resources.
If Faces Servlet has suffix-based mapping, not only path but file 
extensions also should be modified. That is horrible for complex 
libraries like TinyMCE editor that contains hundreds of references to 
scripts, styles and images most of them are assembled in the JavaScript, 
so it is not easy to replace these references even with el evaluation 
enabled.
Also, I'm not convinced that the
> overhead of parsing all CSS on the server is insignificant; has
> it been profiled? We really cannot afford to reduce the performance
> of JSF at all.
It would not be a significant impact for rare changed values and proper 
caching of evaluation results.
Additionally, ResourceHandler decoration sounds like
> a convenient extension point, so that should allow this strategy
> to be applied at any desired granularity.
>
> Ted.
>
>




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