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

[Lincoln Baxter, III]

> 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


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