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

Werner Punz werner.punz at gmail.com
Thu Sep 24 14:00:28 EDT 2009


On Thu, Sep 24, 2009 at 7:22 PM, Andy Schwartz <andy.schwartz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090924/4e70d2ec/attachment.html 


More information about the jsr-314-open-mirror mailing list