[jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified (was: Evaluating EL in resource files)

[Ted Goddard]

I would like to vote as follows:

DefaultToOptOut  +1

The option of having per-resource granularity is preferred.  Note that
per-application configuration becomes very awkward when multiple
frameworks (or existing application code) is combined together in
a single application.

In case you're curious, my interpretation of the feature was that
it was intended for things like:

   var userid = #{user.id};

to allow parameterized JavaScript to be served.  If the goal is simply
to allow JavaScript to load context-relative resources, could this
not be implemented more easily by having the JavaScript side of the
resource loader use a variable context path?  In general, the best
approach would likely be to use relative resource paths.

Regards,
Ted.


On 2009-09-25, at 9:15 AM, Ed Burns wrote:

>>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz <werner.punz at gmail.com 
>>>>>> > said:
>
> WP> Anyway I think this discussion gets a little bit off topic ;-),  
> wasnt it
> WP> about how to apply the el to javascripts originally?
>
> Thank you.  Please take the valuable discussion of caching and  
> resources
> to a separate thread.
>
>> From the previous discussion, I draw two alternatives, which I  
>> place on
> the table for further debate.
>
> OPTION RestrictAllowableExpressions
>
> With this option, we modify Resource.getInputStream() to state that  
> the
> implementation must evaluate EL Expressions in resource files if and
> only if the expression is simple (not compound) and starts with the
> "resource" implicit object.  Handling of any other kinds of EL
> Expressions requires decorating the ResourceHandler.
>
> OPTION DefaultToOptOut
>
> With this option, we modify Resource.getInputstream() to state that EL
> evaluation in Resource files is disabled by default.  For  
> simplicity, I
> suggest the user convey their intention at a per-application  
> granularity
> using a context-param.  If the user does decide to opt-in, all EL
> Expressions in all resources are evaluated every time the resource is
> served.  Resource.getInputStream() will include non-normative text
> alerting the user to possible scope complications.
>
> I prefer RestrictAllowableExpressions because decorating the
> ResourceHandler is an easy way to allow more powerful behavior.
>
> ACTION: Please voice your opinion by 1700 EDT Monday 28 September  
> 2009.
>
> Ed
>
>
> -- 
> | ed.burns at sun.com  | office: 408 884 9519 OR x31640
> | homepage:         | http://ridingthecrest.com/