Re: [jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified
Comments inline.
On 09/28/2009 12:49 PM, Andy Schwartz wrote:
Ed Burns wrote:
>>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz
>>>>>> <werner.punz(a)gmail.com> said:
>
> WP> Anyway I think this discussion gets a little bit off topic ;-),
> wasnt it
> WP> about how to apply the el to javascripts originally?
>
> Thank you. Please take the valuable discussion of caching and resources
> to a separate thread.
>
As Jim's email described, the caching behavior is intimately related to
the question of how to handle EL evaluation in resources. I don't think
that these two discussions really are separate matters.
I agree with the concerns that Jim raised. If we allow arbitrary EL
expressions in resources, then we cannot safely set cache headers. I
think it is very important that JSF provides the ability to
automatically set cache headers - I do not think we should require users
to set up a separate filter for this purpose. (Though if like Lincoln
users prefer to own this responsibility, I am fine with providing some
way to disable this.)
So, I suppose I prefer RestrictAllowableExpressions, since I feel that
allowing arbitrary expressions (DefaultToOptOut) means that we either
need to:
1. Stop setting cache headers. Or...
The proper solution seems to mark resource
that contains el-expressions
non-cacheable and sent cache-control headers otherwise. It's easy to
detect such calls from renderer.
2. Accept the likelihood that users are going to hose themselves in
non-obvious ways. Or...
3. Design a solution that allows a unique URL to be produced for each
unique EL context.
Such solution requires some resource metadata that defines
parameter[s]
to unique identify resource. It can't be done automatically because even
complex file that contains a lot of el references can depend from
something simple like database primary key value, data hashcode or some
UUID, but framework has no clue to guess such key. The same metadata
can be used to solve versioning problem ( go back to xml configuration
file ? ).
I am not happy with either #1 or #2. #3 might be interesting, but seems
like a 2.1 project.
If we do go with DefaultToOptOut then in addition to the above concerns,
I share concerns that others have raised about controlling the opt-in
behavior globally.
BTW, quick question regarding:
> all EL Expressions in all resources are evaluated every time the
> resource is served
Do we check for EL expressions in *all* resources? I assume that we
aren't scanning binary resources (images), right?
Andy