On Wed, 24 Apr 2002, Cliffano Subagio wrote:
I have a variable that would be used globally all over an application,
c:set var=myGlobalVar scope=...Something/c:set
and I put this code in 2 files a.jsp and b.jsp.
What will happen if I use 'application' as the scope value?
Once myGlobalVar is set in a.jsp, what will happen when the same exact code
is encountered in b.jsp? Will it rewrite and overwrite the old myGlobalVar?
or will it ignore the rewriting of the same myGlobalVar since myGlobalVar
is already set with application scope?
And will it behave differently if I set the scope as 'page' in the
same scenario?
There are two questions here, I believe.
The first is, What happens if I try to overwrite an existing scoped
variable (e.g., in application scope)? Here, the answer is simple: you
can always overwrite a scoped variable. Using c:set will either create
or replace a variable; nothing is sticky about the initial c:set.
The second question, I believe, is, What happens if I have an
application-scoped variable named 'foo' and try to set a page-scoped
variable named 'foo'? The answer here, unfortunately, varies by
implementation. The JSP standard technically provides for all scopes to
represent a single namespace: if there is a 'foo' object, it has a single
scope, and you can't have both ${pageScope.foo} and ${sessionScope.foo} at
the same time. However, because the specification doesn't mandate that
containers enforce this behavior, many don't, and (I would guess) most JSP
users expect each scope to have its own namespace.
The general advice that comes from all this is thus twofold:
- There's absolutely no problem overwriting scoped variables within the
same scope.
- Avoid, when possible, using the same name in two different scopes
to ensure your pages are portable from one container to another.
JSTL's tags, like c:set, are neutral on the issue. They don't enforce
more than their containers enforce. So they will let you create a
page-scoped 'foo' if you have an application-scoped 'foo' as long as your
container allows it; use this feature at your own risk.
--
Shawn Bayern
JSP Standard Tag Library http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
