[jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified

[Ken Paulsen]

+1

Jim Driscoll wrote:
> 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