Re: [jsr-314-open] [C036-ElInResources] ACTION: Vote: Resource.getInputStream() underspecified
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