Re: [jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut
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.