Hans says
> The only way the container could distinguish a) > from b) would be
> for it to look at the actual code, and we don't want that do we?
Yes, it would require that. That is why I mentioned the other part of
Shawn's message. That portion is talking about blocks (in the sense of
"{"), which requires looking at the code. My idea was just to define
things this way, without requiring the JSP container to do it (and
without really expecting most containers to do it). Not ideal, but that
would define what is legal and what is not more clearly. Seemed a
reasonable trade-off.
Repeating the relevant portion, I 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.
>
> Regarding where this should be described, JSP.2.3.2 talks about
> start and end tags having to be in the same physical file (and same for
> <% and %>), so that would be a natural place where to say this. But
> Chapter 6 defines what is legal scripting, so that is a natural
> place too. I think I'll see about adding the restriction in 2.3.2 but
> define the concept or matching blocks in scriptlets to Chapter 6
>
====
> I don't see why it's a problem that I need to use different variable names
> in these situations, as long as the container can tell me so with a clear
> error message during the translation phase.
It is not what is done by a number of implementations today, including
Jasper, so this will break existing code.
> It's also exactly what one part
> of JSP 1.1 says (AT_BEGIN/AT_END variables can be used "in the rest of the
> page")
Yes, that is what that part says, but then item 4 in 6.4 specifically
talks about scriptlets affecting scoping of scripting variables, and it
also says that the scope of the object needs not match that of the
scripting variable.
> and it is supported by the requirement that an "id" attribute value
> must be unique within a translation unit (we removed this in 1.2, but that
> was because the spec doesn't mandate that "id" is used to name all variables,
> and to make it possible to use "id" also for NESTED variables).
I don't think that the clause about "id" applies here. That clause
talked about attribues with name "id", and here we are talking about the
exact meaning of AT_BEGIN and AT_END. Maybe I am missing your point?
- eduard/o
====
Hans Bergsten wrote:
>
> Eduardo Pelegri-Llopart wrote:
> >
> > See intermixed...
> >
> > Hans said..
> > > 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.
> >
> > If we add the concept of matching scripting blocks, as it seems needed
> > to declare the other fragment mentioned in Shawn's mail illegal, the
> > container could do it.
>
> I'm not sure I understand what you mean with "matching scripting blocks".
> If it's what I think it is, how would it help the container do the
> right thing in these two situations:
>
> a)
> <% if (...) { %>
> <x:a id="status" />
> <% } %>
> <%= pageContext.getAttribute("status") %>
>
> b)
> <% String a = "foo"; %>
> <x:a id="status" />
> <% String b = "bar" %>
> <%= pageContext.getAttribute("status") %>
>
> With your reasoning, I assume a) should fail ("status" is not in scope,
> and should have been removed by the container) while b) should work (there's
> no nesting of blocks here). The only way the container could distinguish a)
> from b) would be for it to look at the actual code, and we don't want that
> do we?
>
> > I do agree that I am not thrilled with trying to add this at this stage
> > of the JSP 1.2 spec.
> >
> > > 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 ;-)
> >
> > I agree, the area is tricky.
> >
> > > It's so much easier to say that "you can use it anywhere
> > > in the page after this custom action".
> >
> > I think your "it" means "both scripting variable and the object in the
> > pageContext, right?
>
> Right.
>
> > That seems a very strong requirement to me. It seems to require
> > defining the scripting variable at the beginning of the page, which has
> > its own set of usability problems. It also means you cannot do things
> > like
> >
> > <x:iterate id="x">
> > <x:transmogrify out="item" in="x"/>
> > ... you can use item here ...
> > </x:iterate>
> >
> > ... enough stuff here to make it hard to remember what you did ...
> >
> > <x:iterate ...>
> > <x:transmogrify out="item" .../>
> > </x:iterate>
> >
> > Or even more complicated interactions, like adding "item" somewhere in a
> > page and then, through a typo, using it further below in the page.
>
> I don't see why it's a problem that I need to use different variable names
> in these situations, as long as the container can tell me so with a clear
> error message during the translation phase. It's also exactly what one part
> of JSP 1.1 says (AT_BEGIN/AT_END variables can be used "in the rest of the
> page") and it is supported by the requirement that an "id" attribute value
> must be unique within a translation unit (we removed this in 1.2, but that
> was because the spec doesn't mandate that "id" is used to name all variables,
> and to make it possible to use "id" also for NESTED variables).
>
> Similar to what Tom said in reply to my previous mail, I rather be forced to
> *always* use different names than have any confusion about *when* I have to.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
