11:08 a.m.
Question: How does EL parsing in a resource effect the caching headers
sent by the resource handler?
IMO, by default no parsing should be done on any resource and headers
should indicate that the file will not be changed so the browser can
optimize performance.
In the case where the library name is omitted, don't relative URLs
already work (w/o using EL)? So the only case is where we have a library
name and JS / CSS resources which reference additional resources? If
that's the case, I'd punt on the issue and say it's not supported...
users can then serve up their own dynamic resources via a JSF page,
their own resource extension, etc. If a standard develops (assuming
there is a need for this feature), then lets adopt it in a future
release. I'm a little uncomfortable "inventing" a solution, especially
one that may not go over well. Just my 2.5 cents.. ;)
Thanks,
Ken
Ted Goddard wrote:
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(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/