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

[Jason Lee]

I think I agree with Jim's assessment regarding resource-only  
evaluation.  If we restrict to just that one type of EL expression,  
caching becomes much easier.

+1

With regard to relative paths, though, if you're using prefix-mapping,  
won't relative paths work?  I've not tested it, but it seems like they  
ought to:

/myApp/faces/path/to/some/resource.css

which imports ../other/resource.css

That might work, but does require prefix mapping, which, for some odd  
reason, I never use. :)

On Oct 2, 2009, at 5:47 PM, Lincoln Baxter, III wrote:

>> 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.
>
> I suppose this would nullify my agreement with you, Jim ;)
>
> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
> back to +1 again
>
> --Lincoln
>
>
> On Fri, 2009-10-02 at 15:29 -0700, Jim Driscoll wrote:
>>
>> 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
>> >>
> --
> Lincoln Baxter, III
> Co-Founder of OcpSoft
>
> Creator of:
> PrettyFaces: URL rewriting for JSF
> PrettyTime: Java elapsed timestamp formatting
>
>

Jason Lee, SCJP
President, Oklahoma City Java Users Group
Senior Java Developer, Sun Microsystems
http://blogs.steeplesoft.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091003/86a55f30/attachment.html