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

[Jim Driscoll]

OK, I need to make a retraction:

It's been pointed out to me that in cases of the resource being in the 
classpath, then the Resource EL *is* in fact the only way to get those 
files.  relative paths won't cut it.

That's a pretty serious reason to have EL evaluation on CSS.  I 
apologize about the misunderstanding on my part.

So, that means that I need to change my vote:

I'd still like to have only resource EL evaluated.

But, regardless, EL needs to be evaluated, and it's probably common 
enough that it needs to be evaluated that having the default be for all 
CSS files is not unreasonable.

So,

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

+1

Jim


On 10/2/09 2:39 PM, Jim Driscoll wrote:
> 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
>>