Re: [jsr-314-open] Evaluating EL in resource files
On Thu, Sep 24, 2009 at 7:22 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
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
Actually indeed it has been a while since weblets does provide only a
simulation of el functions (which are provided on el level on the jsf side)
which are basically there to be expanded
into a neutral url. It was provided to ensure location independence of
resources and intra bundle resource loading.
The caching only can work because the resources providing those urls
do not change within the scope of an application lifecycle.
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.
The question is what happens to jsf.getProjectStage() on the javascript
side, which more or less has to rely on templating mechanisms to deliver the
project stage. (A bypass for this one on codelevel is needed I assume, or we
have to rely on a second request to get it )
Werner
Attachments:
- attachment.html (text/html — 2.1 KB)