optional variables

[Craig Longman <cr...@begeek.com>]

in a tag i'm creating, it only needs to occasionally set a variable back
into the PageContext.  now, according to all sources, i still need to
setup the variable info (either in the tld or a TEI class), which is
fine.

but, i'm wondering what the concerns with optional variables are.  are
there any general guidelines for performance penalties, etc?  is it
expensive for any reason to declare that you're setting a variable and
then not actually set it?  or perhaps more importantly, is there a
potential for problems if that happens?

-- 

    CraigL->Thx();
    Be Developer ID: 5852

Re: optional variables

[Craig Longman <cr...@begeek.com>]

On Sun, 2002-09-15 at 15:11, Shawn Bayern wrote:
> On 15 Sep 2002, Craig Longman wrote:
> 
> > in a tag i'm creating, it only needs to occasionally set a variable
> > back into the PageContext.  now, according to all sources, i still
> > need to setup the variable info (either in the tld or a TEI class),
> > which is fine.
> 
> Note first that setting a variable "into the PageContext" isn't the same
> thing as setting a scripting variable.

its amazing how clear things seem when someone points out the obvious. 
i was quite confused as to why one had to declare variables that were
going to be set into the PageContext, which i had always assumed was
simply a hashtable of sorts.

thanks very much.

-- 

    CraigL->Thx();
    Be Developer ID: 5852

Re: optional variables

[Shawn Bayern <ba...@essentially.net>]

On 15 Sep 2002, Craig Longman wrote:

> in a tag i'm creating, it only needs to occasionally set a variable
> back into the PageContext.  now, according to all sources, i still
> need to setup the variable info (either in the tld or a TEI class),
> which is fine.

Note first that setting a variable "into the PageContext" isn't the same
thing as setting a scripting variable.

Every scripting variable is simply an automatic variable declared in the
servlet into which your JSP page is compiled.  These scripting variables
are backed by, but not identical with, scoped attributes referenced
through PageContext.  When a tag declares a scripting variable, code like
the following is added to your compiled servlet:

  TYPE varName = (TYPE) pageContext.findAttribute("varName");

> but, i'm wondering what the concerns with optional variables are.  
> are there any general guidelines for performance penalties, etc?  is
> it expensive for any reason to declare that you're setting a variable
> and then not actually set it?

The performance implications are very minor, though nonzero.  As you can
see from the code above, each scripting variable declaration requires a
hashtable lookup and a variable assignment; neither of these are, as a
rule, expensive operations, but if you're concerned about a tag running a
million times in a loop, they could add up in principle.  The only way to
be sure would be through empirical testing.

> or perhaps more importantly, is there a potential for problems if that
> happens?

Well, given that there is no facility for declaring a variable "optional,"
you can run into potential confusion.  The variable *will* be declared
even if you don't assign anything to a scoped attribute; in other words,
the line of code above will run irrespective of the value of the "varName"
scoped attribute.  At worst, the variable will be set to 'null'.  Users
who use such variables won't get a compile-time error; they'll instead get
a NullPointerException if they use it in a situation where 'null' is
invalid.

In general, the "new order" (JSTL + JSP 2.0) suggests that you minimize
the use of scripting variables anyway and simply store data in scopes
(through PageContext) without declaring them as scripting variables.  This
gets around any performance problems you might be concerned with, and it
better fits with the expression language, which can't access scripting
variables (only scoped attributes).

Hope that helps,

-- 
Shawn Bayern
JSTL reference-implementation lead
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>