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

[Alaxander Smirnov]

I think processing of EL expressions should  not be part of 
Resource#getInputStream, at least, not for generic resource.
It would be better to move implementation into resource Renderer, and 
provide some meta-information which should be used for particular 
resource. That would clear divide responsibility between Resource object 
that should only load content from library, and Renderer that knows how 
to send that content to a client.
Using in-place annotations is one way, but it will not work with binary 
content ( images, flash objects, video clips ). I suggest to disable any 
EL-processing by default, but provide optional meta information ( for 
example, as additional file with same name and path as resource but with 
additional ".meta" suffix ) there ResourceHandler can gather additional 
information and change resource processing; the same idea is used by the 
Apache httpd server to define additional response headers for static 
files. These options would be:
1. Resource version. That can resolve the problem how to lookup latest 
version of resource in classpath. ResourceHandler would read all .meta 
files from the same path, and decide which version should be served.
2. Resource Renderer id. Particular renderer can process EL-expressions, 
compress javaScript and CSS in the production stage, or even perform 
more complicated job like rendering of SVG images or compiling  Flex 
applications.
3. Cache control directives. There is no way for framework to guess how 
to distinguish resources with dynamic processing, so developer has to 
provide unique key that can be encoded into resource parameter. For 
example, for CSS it would be current look and feel name.
4. Optional response headers.
6. Optional name of resource file for Development/production stage, so 
developer can provide compressed version of JavaScript or CSS file for 
production stage or include debug output for development stage library.


On 10/03/2009 09:14 PM, Ed Burns wrote:
> From: Imre Osswald<io at mx.jevelopers.com>
>
> I don't think the evaluation should be restricted to resources only.
> Even if it might be confusing that the expressions will/might only be
> evaluated once (especially in production mode), there is great value
> in being able to use "CSS-Vars" to customize the CSS, for example per
> deployment.
> But if every EL is evaluated, then we might need a way to switch
> evaluation off. One example would be:  .sillyExample:before { content:
> "#{might.even.be.used.by.prototype}" };
>
> As I don't see a big performance problem with parsing the css-
> resouces, because of the caching by the browser and by jsf, I would
> like to suggest to have the "switch" to turn evaluation on/off inside
> of the files themselves. Possible solutions could be @-rules like:
> @ELEvaluation "on" / "off";  or probably better "annotation-comments" /
> * @ELEvalution on */
> These could even be used in JS-files, where referencing relative
> resources is not uncommon, and will therefore need resource-evaluation
> too.
>
> As for the defaults: I think ELEvaluationInCSSOnly (= "on") is a
> sensible default, with context options to switch it globally on/off.
> Especially until some sort of switch finds its way into the
> specification.
>
> Imre
>
>