[jsr-314-open] Evaluating EL in resource files

Fri Sep 25 02:55:11 EDT 2009

On Thu, Sep 24, 2009 at 11:31 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

>  Hmm... I suppose I've been considering it from the other angle.
>
> Resources allow abstraction between physical location and URI. Just so I've
> got this straight: We are talking about things like .css files, .js files,
> and images when we say 'resources', right?
>
> If so, I still feel as if automatically supplying browser cache headers is
> un-intuitive. How long is the default cache-expiry? What if I want to change
> that? Where do I start? Is this something people are used to having done for
> them?
>
> I think this is less an implementation more a documentation issue since all
the apis are there
to write a custom resource handler and it is no rocket science doing it.

So it comes down to, if you want the defaults use what is given if you need
special more fine grained control write your own resource handler, that way
you can influence cache eviction times etc...

As for people are used to having done for them. I can only speak from a
Weblets point of view. We provide basic defaults which are cache on afair,
but we have configuration options for cache-timeouts and anything beyound
that needs a custom Weblet.
For enforcing version updates without having even to tamper with timeout
times, we have the version numbers which are part  of the url. (Same as JSF
which however does it on resource level not on bundle level), which is a
cleaner resource update mechanism than tampering with cache control times,
because it gives you a clean timed interception point for enforcing an
update in a browser neutral way!

I have yet to say I am not sure if I have used the timeout option so far,
except for turning off the cache explicitely, but there are corner cases,
where you want to provide it. Probably most cases would have been covered
with cache-off  and cache-on + version numbers.

One of the reasons for using a resource library simply is that you dont have
to wrap your brain around anymore about the various pitfalls of cache
control, regarding the various browser versions and have the library doing
it for you.
I would not want to use a resource library without this option and sane
defaults doing the heavy lifting for me.

Anyway I think this discussion gets a little bit off topic ;-), wasnt it
about how to apply the el to javascripts originally?

Werner

If someone wants to serve resources from a Database, they need to write a
> custom ResourceHandler, in which case they won't benefit from the caching
> the DefaultResourceHandler provides anyway. Serving local files is probably
> the least of our worries when it comes to caching.
>
> -Lincoln
>
>
> On Thu, 2009-09-24 at 13:42 -0700, Ken Paulsen wrote:
>
> There are lots of reasons besides caching.  Mostly having to do with the
> locating and serving of bits.  However, the **default** ResourceHandler
> should do what most people expect it to do -- and my belief is that
> means it should cache all content.  A flag (such as the development
> phase flag) can and should disable caching for development only...
>
> If someone wants to serve resources from a Database, ldap, generated via
> Java code, web services, etc.... then they need a custom Resource and
> perhaps a custom ResourceHandler.  I think this gives very good
> fine-grained control to the advanced developer.
>
> Ken
>
> Jim Driscoll wrote:
> > Naive question:  If we don't do cache control on resources, what's the
> > point of resources?  I had thought the whole point was automatically
> > segmenting your application into dyanmic, uncached pages, and static,
> > cached pages.  At least, that's the major benefit that I've been
> > telling people.
> >
> > Jim
> >
> > On 9/24/09 12:08 PM, lincolnbaxter at gmail.com wrote:
> >> I agree partly :)
> >>
> >> My vote is for no auto-caching, and allowing all scopes.
> >>
> >> I don't see any problem providing access to all scopes in these files
> >> if caching is not default. Caching is such a sensitive subject, and
> >> is one area where I feel the intuitive route is to omit functionality.
> >>
> >> If caching is on by default, I think logging a warning is acceptable
> >> feedback when a dev uses request or session scope in a resource file.
> >> If we want to hard stop it (not my favorite idea,) then disallowing
> >> these scopes is the only way to go, I suppose.
> >>
> >> Maybe its just me, but I prefer controlling cache headers myself.
> >>
> >> Lincoln
> >>
> >>
> >> Sent from my Verizon Wireless BlackBerry
> >>
> >> -----Original Message-----
> >> From: Ryan Lubke<Ryan.Lubke at Sun.COM>
> >>
> >> Date: Thu, 24 Sep 2009 11:50:23
> >> To:<jsr-314-open at jcp.org>
> >> Subject: Re: Evaluating EL in resource files
> >>
> >>
> >> On 9/24/09 10:22 AM, Andy Schwartz wrote:
> >>> Ken Paulsen wrote:
> >>>>
> >>>> Question: How does EL parsing in a resource effect the caching
> >>>> headers sent by the resource handler?
> >>>>
> >>>
> >>> I was wondering the same thing.  Ideally every resource that we serve
> >>> up should specify http headers to encourage browser caching.  Allowing
> >>> EL expressions in resource content of course complicates this.  If we
> >>> want to allow arbitrary expressions then either:
> >>>
> >>> 1. We cannot allow these resources to be cached (bad).  Or...
> >>> 2. We need some way to ensure that every resource URL is always mapped
> >>> to the same content (ie. EL expressions will always evaluate to the
> >>> same result for any given URL).
> >>>
> >>> For #2, this might mean allowing a resource to tweak the URL in order
> >>> to add information that ensures that the URL reflects the any EL
> >>> dependencies.
> >>>
> >>> In the examples that Ed gave, it seems possible that the EL
> >>> expressions such as this:
> >>>
> >>> #{resource['this:layout.css']}
> >>>
> >>> Would in fact always evaluate to the same value for any particular
> >>> resource URL.  If this were the case, then we could safely set cache
> >>> headers for such resources.
> >>>
> >>> However, if arbitrary EL is allowed (eg. EL that references
> >>> request/session scope data), then we must either do #1 or #2 above.
> >>>
> >>> Should we consider placing some limits on what types of EL expressions
> >>> are allowed/resolved?  For starters, possibly only provide access to
> >>> #{resource} expressions?  If these are guaranteed to evaluate the same
> >>> for each requested URL, we should be able to cache these resources.
> >> This is what I believe was intended (I recall pointing this out some
> >> time back during some internal discussions).  The expressions should be
> >> limited to results that aren't going to change between requests because
> >> of caching semantics.
> >>>
> >>> Imposing such a limitation might also help us to reduce the chance of
> >>> collisions with Prototype's use of #{}.
> >>>
> >>> BTW, Weblets provides similar functionality:
> >>>
> >>> https://weblets.dev.java.net/doc_11/longdoc/usageresources.html
> >>>
> >>> The solution appears to be limited to resolving Weblet resource URLs
> >>> (does not support arbitrary expressions).  This functionality is
> >>> similar in scope to my suggestion above.
> >>>
> >>> Andy
> >>>
> >>>
> >>
>
>   --
> *Lincoln Baxter, III*
> Co-Founder of OcpSoft <http://ocpsoft.com>
>
> Creator of:
> PrettyFaces <http://ocpsoft.com/prettyfaces>: URL rewriting for JSF
> PrettyTime <http://ocpsoft.com/prettytime>: Java elapsed timestamp
> formatting
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090925/aa9c4dc2/attachment.html 