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/

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/

Question: How does EL parsing in a resource effect the caching headers sent by the resource handler?

Sorry for short reply. Blackberry. Isn't caching controlled by devs already? I had to add a response header filter to my app to control this.

Should we consider placing some limits on what types of EL expressions are allowed/resolved? For starters, possibly only provide access to #{resource} expressions? If these are guaranteed to evaluate the same for each requested URL, we should be able to cache these resources. Imposing such a limitation might also help us to reduce the chance of collisions with Prototype's use of #{}. BTW, Weblets provides similar functionality: https://weblets.dev.java.net/doc_11/longdoc/usageresources.html

The solution appears to be limited to resolving Weblet resource URLs (does not support arbitrary expressions). This functionality is similar in scope to my suggestion above.

Ken Paulsen wrote: > > Question: How does EL parsing in a resource effect the caching > headers sent by the resource handler? > I was wondering the same thing. Ideally every resource that we serve up should specify http headers to encourage browser caching. Allowing EL expressions in resource content of course complicates this. If we want to allow arbitrary expressions then either: 1. We cannot allow these resources to be cached (bad). Or... 2. We need some way to ensure that every resource URL is always mapped to the same content (ie. EL expressions will always evaluate to the same result for any given URL). For #2, this might mean allowing a resource to tweak the URL in order to add information that ensures that the URL reflects the any EL dependencies. In the examples that Ed gave, it seems possible that the EL expressions such as this: #{resource['this:layout.css']} Would in fact always evaluate to the same value for any particular resource URL. If this were the case, then we could safely set cache headers for such resources. However, if arbitrary EL is allowed (eg. EL that references request/session scope data), then we must either do #1 or #2 above. Should we consider placing some limits on what types of EL expressions are allowed/resolved? For starters, possibly only provide access to #{resource} expressions? If these are guaranteed to evaluate the same for each requested URL, we should be able to cache these resources.

Imposing such a limitation might also help us to reduce the chance of collisions with Prototype's use of #{}. BTW, Weblets provides similar functionality: https://weblets.dev.java.net/doc_11/longdoc/usageresources.html The solution appears to be limited to resolving Weblet resource URLs (does not support arbitrary expressions). This functionality is similar in scope to my suggestion above. Andy

I agree partly :) My vote is for no auto-caching, and allowing all scopes. I don't see any problem providing access to all scopes in these files if caching is not default. Caching is such a sensitive subject, and is one area where I feel the intuitive route is to omit functionality. If caching is on by default, I think logging a warning is acceptable feedback when a dev uses request or session scope in a resource file. If we want to hard stop it (not my favorite idea,) then disallowing these scopes is the only way to go, I suppose. Maybe its just me, but I prefer controlling cache headers myself. Lincoln Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Ryan Lubke&lt;Ryan.Lubke(a)Sun.COM&gt; Date: Thu, 24 Sep 2009 11:50:23 To:<jsr-314-open@jcp.org> Subject: Re: Evaluating EL in resource files On 9/24/09 10:22 AM, Andy Schwartz wrote: > Ken Paulsen wrote: >> >> Question: How does EL parsing in a resource effect the caching >> headers sent by the resource handler? >> > > I was wondering the same thing. Ideally every resource that we serve > up should specify http headers to encourage browser caching. Allowing > EL expressions in resource content of course complicates this. If we > want to allow arbitrary expressions then either: > > 1. We cannot allow these resources to be cached (bad). Or... > 2. We need some way to ensure that every resource URL is always mapped > to the same content (ie. EL expressions will always evaluate to the > same result for any given URL). > > For #2, this might mean allowing a resource to tweak the URL in order > to add information that ensures that the URL reflects the any EL > dependencies. > > In the examples that Ed gave, it seems possible that the EL > expressions such as this: > > #{resource['this:layout.css']} > > Would in fact always evaluate to the same value for any particular > resource URL. If this were the case, then we could safely set cache > headers for such resources. > > However, if arbitrary EL is allowed (eg. EL that references > request/session scope data), then we must either do #1 or #2 above. > > Should we consider placing some limits on what types of EL expressions > are allowed/resolved? For starters, possibly only provide access to > #{resource} expressions? If these are guaranteed to evaluate the same > for each requested URL, we should be able to cache these resources. This is what I believe was intended (I recall pointing this out some time back during some internal discussions). The expressions should be limited to results that aren't going to change between requests because of caching semantics. > > Imposing such a limitation might also help us to reduce the chance of > collisions with Prototype's use of #{}. > > BTW, Weblets provides similar functionality: > > https://weblets.dev.java.net/doc_11/longdoc/usageresources.html > > The solution appears to be limited to resolving Weblet resource URLs > (does not support arbitrary expressions). This functionality is > similar in scope to my suggestion above. > > Andy > >

There are lots of reasons besides caching. Mostly having to do with the locating and serving of bits. However, the **default** ResourceHandler should do what most people expect it to do -- and my belief is that means it should cache all content. A flag (such as the development phase flag) can and should disable caching for development only... If someone wants to serve resources from a Database, ldap, generated via Java code, web services, etc.... then they need a custom Resource and perhaps a custom ResourceHandler. I think this gives very good fine-grained control to the advanced developer.

Ken Jim Driscoll wrote: > Naive question: If we don't do cache control on resources, what's the > point of resources? I had thought the whole point was automatically > segmenting your application into dyanmic, uncached pages, and static, > cached pages. At least, that's the major benefit that I've been > telling people. > > Jim > > On 9/24/09 12:08 PM, lincolnbaxter(a)gmail.com wrote: >> I agree partly :) >> >> My vote is for no auto-caching, and allowing all scopes. >> >> I don't see any problem providing access to all scopes in these files >> if caching is not default. Caching is such a sensitive subject, and >> is one area where I feel the intuitive route is to omit functionality. >> >> If caching is on by default, I think logging a warning is acceptable >> feedback when a dev uses request or session scope in a resource file. >> If we want to hard stop it (not my favorite idea,) then disallowing >> these scopes is the only way to go, I suppose. >> >> Maybe its just me, but I prefer controlling cache headers myself. >> >> Lincoln >> >> >> Sent from my Verizon Wireless BlackBerry >> >> -----Original Message----- >> From: Ryan Lubke&lt;Ryan.Lubke(a)Sun.COM&gt; >> >> Date: Thu, 24 Sep 2009 11:50:23 >> To:<jsr-314-open@jcp.org> >> Subject: Re: Evaluating EL in resource files >> >> >> On 9/24/09 10:22 AM, Andy Schwartz wrote: >>> Ken Paulsen wrote: >>>> >>>> Question: How does EL parsing in a resource effect the caching >>>> headers sent by the resource handler? >>>> >>> >>> I was wondering the same thing. Ideally every resource that we serve >>> up should specify http headers to encourage browser caching. Allowing >>> EL expressions in resource content of course complicates this. If we >>> want to allow arbitrary expressions then either: >>> >>> 1. We cannot allow these resources to be cached (bad). Or... >>> 2. We need some way to ensure that every resource URL is always mapped >>> to the same content (ie. EL expressions will always evaluate to the >>> same result for any given URL). >>> >>> For #2, this might mean allowing a resource to tweak the URL in order >>> to add information that ensures that the URL reflects the any EL >>> dependencies. >>> >>> In the examples that Ed gave, it seems possible that the EL >>> expressions such as this: >>> >>> #{resource['this:layout.css']} >>> >>> Would in fact always evaluate to the same value for any particular >>> resource URL. If this were the case, then we could safely set cache >>> headers for such resources. >>> >>> However, if arbitrary EL is allowed (eg. EL that references >>> request/session scope data), then we must either do #1 or #2 above. >>> >>> Should we consider placing some limits on what types of EL expressions >>> are allowed/resolved? For starters, possibly only provide access to >>> #{resource} expressions? If these are guaranteed to evaluate the same >>> for each requested URL, we should be able to cache these resources. >> This is what I believe was intended (I recall pointing this out some >> time back during some internal discussions). The expressions should be >> limited to results that aren't going to change between requests because >> of caching semantics. >>> >>> Imposing such a limitation might also help us to reduce the chance of >>> collisions with Prototype's use of #{}. >>> >>> BTW, Weblets provides similar functionality: >>> >>> https://weblets.dev.java.net/doc_11/longdoc/usageresources.html >>> >>> The solution appears to be limited to resolving Weblet resource URLs >>> (does not support arbitrary expressions). This functionality is >>> similar in scope to my suggestion above. >>> >>> Andy >>> >>> >>

( it is important not to use URL parameters for that purpose, because some caching proxies, like Squid, recognize '?' character in url and process these requests as non-caching even thought cache-control headers mark response as cacheable. It also seems what some browsers do the same. ).

On 09/25/2009 12:15 PM, Jim Driscoll wrote: > On 9/25/09 10:35 AM, Alexander Smirnov wrote: >> ( it is important not to use URL >> parameters for that purpose, because some caching proxies, like Squid, >> recognize '?' character in url and process these requests as non-caching >> even thought cache-control headers mark response as cacheable. It also >> seems what some browsers do the same. ). > > OK, that's alarming. > > I don't much care if caching proxies ignore perfectly good Expires: > headers, so long as they pass them on. But if a browser does, that's a > strong argument against that approach. It's also surprising, since the > whole idea of using parameters on JavaScript was taken from other, > popular JavaScript libraries in common use - scriptaculous, to name just > one. > > Do you know which, if any, browser which does this? I'd like to test > that assertion, and see if there's any way around it. I do not remember exact browser versions ( the library was developed about 3 years ago, while we spent a lot of time to fine tuning cache control ), but I can recall such problems with MS IE 6.0. I can look up in the project history, but it could take a while. For Squid proxy, it is part of standard configuration. Administrator can remove this pattern, but most leave standard values untouched. > > Jim