Re: [jsr-314-open] Evaluating EL in resource files
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<Ryan.Lubke(a)Sun.COM>
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
>
>