+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