5:19 p.m.
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