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

[lincolnbaxter at gmail.com]

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. 

Perhaps I'm missing the point. Is JSF caching these resources automatically?
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Andy Schwartz <andy.schwartz at oracle.com>

Date: Thu, 24 Sep 2009 13:22:15 
To: <jsr-314-open at jcp.org>
Subject: Re: [jsr-314-open] Evaluating EL in resource files


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