[jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut

[Jim Driscoll]

Since EL evaluation in CSS will continue to have all the problems that I 
mentioned earlier for JavaScript (performance and caching), and since 
CSS files are fully capable of loading other resources through relative 
paths, I'd like to voice mild opposition to the idea.

ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly

-1


I'd instead prefer that we either:

1) Don't evaluate anything in any resource until we sort out the best 
way to handle the performance and caching implications

or, as a fallback

2) We evaluate only resource EL in CSS, with a context param that has to 
be enabled for it to work (i.e., off by default - since it will decrease 
performance and only need to be used in occasional cases).  I'd 
especially not like to rely on "magic strings" in the file name for this 
- there's bound to be a better way implemented in 2.1, and I'd prefer 
not to tie us to a brittle mechanism going forward.

But as I said - my opposition to this is only mild - it's certainly not 
the problem here that it would be in JavaScript - but once we allow it, 
we can't "unallow" it when a better method comes along.

Jim

On 10/2/09 1:23 PM, Ed Burns wrote:
> First, let me say I think we need to quickly make a statement in the
> ChangeLog about this because not having this feature, at least in CSS
> resources, is a big shortcoming for Resource loading.  Note that Mojarra
> currently does have this in *all* resources and I requested Ryan to make
> it for just CSS CSS resources to provide a solution for Ted Goddard's
> immediate problem regarding the prototype JavaScript library.
>
> EB>  OPTION DefaultToOptOut
>
> EB>  With this option, we modify Resource.getInputstream() to state that EL
> EB>  evaluation in Resource files is disabled by default.  For simplicity, I
> EB>  suggest the user convey their intention at a per-application granularity
> EB>  using a context-param.
>
> This was the most popular option, but no-one was in favor of the context
> param; everyone that voted wanted a finer grain solution.
>
> AS>  As Jim's email described, the caching behavior is intimately related to
> AS>  the question of how to handle EL evaluation in resources.  I don't think
> AS>  that these two discussions really are separate matters.
>
> Yes, I see your point that they are related.  However, we chose to say
> nothing about cache headers and resources in 2.0.  Therefore, I think
> what we say about cache headers and resources should wait for the next
> JCP release of JSF.
>
> On the other hand, as I said above, I think the absence of a way for
> resources to refer to other resources is a missing feature.  I intended
> to specify it in Resource.getInputStream(), but I failed to do so
> through an error on my part.  Therefore, I'm going to place another
> option on the table for inclusion in the ChangeLog.
>
> OPTION ELEvaluatedInCSSOnly
>
> With this option, we modify Resource.getInputStream() to state that EL
> evaluation in CSS files is enabled by default.  We will state that care
> must be taken by the user to ensure that the EL expression always
> evaluates to the same thing across multiple requests.  We will state
> that the user may decorate the ResourceHandler to get more flexibility.
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>
> Thanks,
>
> Ed
>