Re: [jsr-314-open] Evaluating EL in resource files
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(a)oracle.com>
Date: Thu, 24 Sep 2009 13:22:15
To: <jsr-314-open(a)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