> > A better solution would be a to make a PAGE_WIDE scope available
> > to tag authors.
>
> But surely the variable won't be valid/initialised until the tag has
> executed.
Right, but a null value will surely jump up in the face of the
user so he can quickly correct it.
> > In fact I would question the utility of AT_BEGIN
> > and AT_END if such a scope existed. With these lexical scoping
> > exceptions the only way to make sense of AT_END and AT_BEGIN
>
> I take AT_BEGIN and AT_END to mean that the tag-defined
> scripting variable
> is initialised in doStartTag/doEndTag respectively, I don't
> particularly
> care where it's declared as long as the user of the tag knows
> when it's safe
> to use the variable.
I agree but it makes a big difference where its declared. Example:
<tag id="foo"/>
...
<tag id="foo"/>
This will result in duplicate variable declarations under the tightly scoped
interpretation but will work if foo is declared at the top level scope (and
the engine is smart about not declaring the same variable twice, which is
easy if all AT_END and AT_BEGIN variables are declared in the same place).
<if ...>
<tag id="foo"/>
</if>
<if ...>
<tag id="foo"/>
</if>
This one works under both approaches but fails as soon as the user takes one
of the tags outside the <if> when using the tightly scoped approach (Java
doesn't let nested local scopes shadow each other like C). I think
both should work.
I did some research on the Jakarta taglibs and while most scripting vars
are NESTED around %10-%20 are AT_BEGIN or AT_END and every single one
of them has declare set to true. This leads me to believe there may
be merit the alternate approach of not scoping scripting variables
introduced by tags and that no one is using the declareObjects
workaround. The reason declare is set to true is so the user doesn't
have to declare it, not because the tag wants the variable to be
tightly scoped should the tag occur inside another tag.
The rationale is that everyone of these AT_END/AT_BEGIN variables that
has declare=true is going to cause developers problems with they try
to use the same tag twice with the same identifier. You can argue that
a strict systems language like Java shouldn't allow that but I see no
reason to force that on JSP developers. Why not let them reuse the same
variable? They already can in certain circumstances (when they are both
nested) and I think its asking for trouble to have it work in some
circumstances and not in others.
> > is to think about the underlying generated code which JSP users
> > shouldn't have to do.
>
> No, but users if JSP have to understand how the environment
> works, and users
> of a tag have to understand the semantics of that tag. If we
> don't trust
> them to do that then we shouldn't be letting them loose with
> Java code and
> script variables :-)
Who's to say they are going loose with Java code? A couple engines
support writing JSP pages in JavaScript and they never have to worry about
this. We've also had requests for switches to turn off support for <%! %>
and <% %> (I never thought it would turn out to be a feature but you
can do this with JRun ;-)
The question to ask is what do we gain by a tight scoping interpretation?
I can't think of anything and I think its pretty clear we're taking a hit
in the usability department by going that route.
