I agree, the frustration from unknowningly reusing a variable
and getting confused about whats going on in the page would probably
be worse than having the container give you an error telling you to
use a different name.
> -----Original Message-----
> From: Hans Bergsten [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 7:04 PM
> To: Eduardo Pelegri-Llopart
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: (JSP) Re: AT_BEGIN, AT_END
>
>
> 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
>
