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

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 >>> >>> >>