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

[Alexander Smirnov]

On 09/24/2009 01:42 PM, Ken Paulsen wrote:
>
> 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.
>
We are already introduced such ResourceHandler for RichFaces 
skinnability needs. It would be our contribution for JSF 2.1.
> 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 at 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<Ryan.Lubke at Sun.COM>
>>>
>>> Date: Thu, 24 Sep 2009 11:50:23
>>> To:<jsr-314-open at 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
>>>>
>>>>
>>>