>>>>> 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. > From the previous discussion, I draw two alternatives, which I > place on the table for further debate. OPTION RestrictAllowableExpressions With this option, we modify Resource.getInputStream() to state that the implementation must evaluate EL Expressions in resource files if and only if the expression is simple (not compound) and starts with the "resource" implicit object. Handling of any other kinds of EL Expressions requires decorating the ResourceHandler. OPTION DefaultToOptOut With this option, we modify Resource.getInputstream() to state that EL evaluation in Resource files is disabled by default. For simplicity, I suggest the user convey their intention at a per-application granularity using a context-param. If the user does decide to opt-in, all EL Expressions in all resources are evaluated every time the resource is served. Resource.getInputStream() will include non-normative text alerting the user to possible scope complications. I prefer RestrictAllowableExpressions because decorating the ResourceHandler is an easy way to allow more powerful behavior. ACTION: Please voice your opinion by 1700 EDT Monday 28 September 2009. Ed -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/

On 9/25/09 9:04 AM, Ted Goddard wrote: > In case you're curious, my interpretation of the feature was that > it was intended for things like: > > var userid = #{user.id}; There's a serious problem with relying on this kind of use, and I want to make sure that everyone understands it fully. Since the default for resources is to have the expires header set in the far future, whatever you serve had better never change for the lifetime of the browser instance. Otherwise, you'll be using faulty data. Let's take the example of a user ID - if you serve up a javascript file with the user's ID in it, that javascript file will never expire - even if the user logs out, and then logs back in as a different user. And that kind of error will be very, very hard to debug for the enduser or application author. In fact, there's a very limited number of instances where this feature will actually come in handy as a result - static final application scoped variables spring to mind (but in that case, why didn't you use a config file, or hardcode in the js file itself?). But even there, you'd better not be sharing JS across applications. Some facescontext variables (but again, that could be hardcoded - after all, it never changes). But for any of those cases, you could just as easily rely on the loading page to pass those variables into the JS, without any of those caching worries. In fact, it's my contention that for most variables that you'll want to pass in to your JavaScript, you'll have to rely on an init method, just like I do in most of my ajax component blogs. User id would be one example of many. In fact, since there's a significant performance overhead for eval of these variables, and this features is likely to be a font of bugs for app developers, and since I can't think of a use case that couldn't also be better handled with an init method that initializes a context inside the JS file, I'd like to recommend that we simply disallow JavaScript EL evaluation altogether - it's just far too likely to cause confusion and bugs - we've already seen examples of this. Resource loading can be done via relative paths easily enough, yes? We can always revisit the decision in 2.1, when we'll presumably also talk about user accessable cache control. EL in JavaScript without that cache control just doesn't really make sense. Jim

>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz&lt;werner.punz(a)gmail.com&gt; 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. > From the previous discussion, I draw two alternatives, which I place on the table for further debate. OPTION RestrictAllowableExpressions With this option, we modify Resource.getInputStream() to state that the implementation must evaluate EL Expressions in resource files if and only if the expression is simple (not compound) and starts with the "resource" implicit object. Handling of any other kinds of EL Expressions requires decorating the ResourceHandler. OPTION DefaultToOptOut With this option, we modify Resource.getInputstream() to state that EL evaluation in Resource files is disabled by default. For simplicity, I suggest the user convey their intention at a per-application granularity using a context-param. If the user does decide to opt-in, all EL Expressions in all resources are evaluated every time the resource is served. Resource.getInputStream() will include non-normative text alerting the user to possible scope complications. I prefer RestrictAllowableExpressions because decorating the ResourceHandler is an easy way to allow more powerful behavior. ACTION: Please voice your opinion by 1700 EDT Monday 28 September 2009. Ed

Ed Burns wrote: >>>>>> On Fri, 25 Sep 2009 08:55:11 +0200, Werner Punz >>>>>> <werner.punz(a)gmail.com&gt; 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...

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.

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