Re: [jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified (was: Evaluating EL in resource files)
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(a)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(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/