jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <h...@gefionsoftware.com>
Subject Re: (JSP) Re: AT_BEGIN, AT_END
Date Wed, 23 May 2001 16:11:31 GMT
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		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

Mime
View raw message