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

[Ken Paulsen]

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