[jsr-314-open] Evaluating EL in resource files

Ted Goddard ted.goddard at icesoft.com
Thu Sep 24 11:43:32 EDT 2009


Or perform EL parsing only when the filename ends with -el?

It's very likely that EL parsing will also corrupt some CSS files
(or other, future content types), so there should be an explicit
opt-in mechanism.  (There is also the overhead of parsing to be
saved, since only a minority of resources will contain EL expressions.)

Regards,
Ted.

On 2009-09-24, at 7:53 AM, Ed Burns wrote:

> Greetings EG,
>
> We have two problems here.  First, let me restate the intent of the
> feature.
>
> FEATURE SHORT DESCRIPTION:
> ==========================
>
> Let JSF2 resources refer to other resources in a way that the browser
> can make GET requests to load them via the ResourceHandler.
>
> RATIONALE for FEATURE:
> ======================
>
> CSS files may refer to other files using the following syntax
>
> url( some URL )
>
> The url() element may appear in several places in a CSS file, most
> commonly to the right of @import, as in
>
> @import url(layout.css)
> @import url(typography.css)
> @import url(colorAndMedia.css)
>
> Unfortunately, this doesn't "just work" when the CSS file in  
> question is
> in a JSF resource library, for obvious reasons.
>
> The solution we chose was to allow EL expressions in CSS files.  That
> way, you could say this in your css file:
>
> @import url(#{resource['this:layout.css']})
> @import url(#{resource['this:typography.css']})
> @import url(#{resource['this:colorAndMedia.css']})
>
> and when the file actually gets served up it would look like:
>
> @import url(/jsf-ezcomp02/javax.faces.resource/layout.css.jsf? 
> ln=ezcomp);
> @import url(/jsf-ezcomp02/javax.faces.resource/typography.css.jsf? 
> ln=ezcomp);
> @import url(/jsf-ezcomp02/javax.faces.resource/colorAndMedia.css.jsf? 
> ln=ezcomp);
>
> PROBLEM 1. This behavior should have been specified in the javadocs  
> for
> Resource.getInputStream().  I've added this to the ChangeLog.
>
> PROBLEM 2.  JavaScript resources have the same problem; they can refer
> to other javascript files and the browser needs to know how to fetch
> them.  We employed the same solution: put EL in there and it gets
> evaluated on the way out.
>
> Unfortunately, the prototype JavaScript library uses #{} to mean
> something important.
>
> SUGGESTED SOLUTION to PROBLEM 2.
>
> Let's assume PROBLEM 1 didn't exist.  I suggest we modify the spec for
> getInputStream() to say that all resources EXCEPT JavaScript  
> resources,
> must do the EL evaluation on the way out.  We need some way for  
> users to
> enable the feature for JavaScript resources because, let's face it,  
> not
> everyone uses prototype.  Ryan and I suggest we adopt a protocol that
> says, "if the resource name ends in '-el' we always turn on the EL
> evaluation on the way out".
>
> Thoughts?
>
> Ed
>
> -- 
> | ed.burns at sun.com  | office: 408 884 9519 OR x31640
> | homepage:         | http://ridingthecrest.com/






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