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

[Alexander Smirnov]

Yes, that is known problems. Just for information, I'll describe here 
how it was solved in the RichFaces framework:
1) We use different file extensions to distinguish should they be 
processed or not. Framework decides which renderer will process 
particular resource, and it is up to renderer implementation to process 
el-expressions or not and how to set proper cache-control headers for 
response. JSF 2.0 does that in the similar way, but only knows about 
".css" and ".js" yet, so it would be  easily done in similar way.
2) To cache dynamic-generated resources, we encode parameters that 
uniquely define resource into URL path ( it is important not to use URL 
parameters for that purpose, because some caching proxies, like Squid, 
recognize '?' character in url and process these requests as non-caching 
even thought cache-control headers mark response as cacheable. It also 
seems what some browsers do the same. ). For example, skin system 
calculates hash code for current settings and use that to generate CSS 
files and images. Because value and meaning of these parameters are 
different for different resources, renderer encapsulates URL generation 
and processing, so we sure what it will be processed in the same way.
3) To speed-up resource processing, the same parameter is used as 
server-side key, so any request for already generated resource does not 
trigger rendering again but sends result from server cache.


On 09/24/2009 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.
>
> 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
>
>