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

[Jim Driscoll]

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