Eduardo Pelegri-Llopart wrote:
>
> Shawn is asking clarifications on some of the scoping rules.
>
> Let me start with his second question. He asks whether the following is
> legal or illegal JSP:
>
> 1 | <% if (a == b) { %>
> 2 | <x:tag>
> 3 | <% } >
> 4 |
> 5 | ...
> 6 |
> 7 | <% if (a == b) { %>
> 8 | </x:tag>
> 9 | <% } %>
>
> Good point. I think the answer should be "illegal" but I don't see
> where the spec specifically says so.
>
> I propose we add some verbiage about matching blocks in scripting code
> to the spec (in this case, in lines 1 and 3, and then in 7 and 9) and
> specify that custom actions need to appear completely within them.
> [...]
I agree.
> Shawn is also asking about the visibility for an example of the form:
>
> > > <x:b>
> > > <x:a/>
> > > </x:b>
> > > <%= status %>
>
> where x:a is defining a scripting variable "status" as AT_BEGIN
> (AT_END would do as well).
>
> There are two parts. One is the life of the object within the
> pageContext object; the other is the scope of the scripting variable.
> I.e. the first is part is, when can I do a page.getAttribute("status")
> and get that object. The second is where can one use the "status"
> scripting variable.
>
> The spec seems to suggest that the scope of the object in pageContext
> is from the moment the start tag is invoked until the end of
> the page. But the transformation in Section JSP.6.4, and the comment at
> the end of that section (plus Shawn's observation about implementation
> details) says that the scripting variable is actually scoped by the
> <x:b> and </x:b>
>
> This is a bit strange, so one possibility would be to clarify the two
> scopes should be the same, e.g. modify the semantics of AT_BEGIN and
> AT_END so they are interpreted within the enclosed scope of the tag,
> using some verbiage similar to that in 6.4.4. That would require
> changes in Section 10.5.8 (page 200).
>
> This also requires implementation changes, i.e. the JSP container would
> be responsible for removing the pageContext binding for "status" after
> the end tag in x:b.
>
> I would appreciate opinions on this.
I see two problems with going this way:
1) The container will likely have a hard time to deal with these two
cases consistently:
a)
<foo:if ...>
<x:a id="status" />
</foo>
<%= pageContext.getAttribute("status") %>
b)
<% if (...) { %>
<x:a id="status" />
<% } %>
<%= pageContext.getAttribute("status") %>
In a) it can remove "status" from the pageContext but it's not as easy
for it to do so in b). To a JSP page author, these cases are the same
though.
2) In general, explaining to a non-programmer the concept variable
visibility and how the different interactions of custom actions and
scripting elements affect where a variable can be used doesn't
thrill me ;-) It's so much easier to say that "you can use it anywhere
in the page after this custom action".
Tom Reilly said in another mail in this thread:
> The other solution is to modify things so that the scope of the
> scripting variable matches the scope of the variable in the
> pageContext. This has two ramifications:
>
> - the JSP engine has to lift the declaration of the variable out of
> any scopes its in
> - the scripting variable is available before its set, presumably
> initialized to null (the bit about the compiler throwing errors on
> uninitialized variables doesn't work when the value gets set inside
> a conditional block as Shawn pointed out to me).
This looks like a much better solution to me. But Tom also goes on to
say, in yet another mail:
> [...] 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).
I would prefer if this is still controlled by the declare value in
VariableInfo. In other words, if declare=true, both of Tom's examples would
be invalid (needed to be reported by the container directly, not indirectly
as a Java compilation error):
1)
<tag id="foo"/>
...
<tag id="foo"/>
2)
<if ...>
<tag id="foo"/>
</if>
<if ...>
<tag id="foo"/>
</if>
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
