possibly useful feature comments please

[Morris Hirsch <mo...@mama.stg.brown.edu>]

Tags generate java code, which if all goes well we never need to see.

If all does not go well, we get error messages in terms of that code,
and could understand them better if we did see the code,
or perhaps better yet, if an error was related to the tag.

A trace utility could do that if every snip of generated code
 was clearly linked to the tag it came from.  When lex and yacc
generate C code, they keep track of the original line numbers,
and pass them along as special comments in the C code.

Would this be helpful in JSP?

thanks for any thoughts on this,

Morris Hirsch


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: possibly useful feature comments please

[Shawn Bayern <ba...@essentially.net>]

Hi Morris,

Thanks for the suggestion.

It's typical for a JSP container to print line numbers for the JSP source
that corresponds to Java output.  This is useful for users that want to
examine the Java source themselves, but it doesn't lead automatically to
better error messages.  To report clearer errors, the Java compilers
themselves would need to process this information in order to print out
more useful error messages (for the compilation errors you see come from
the compiler itself).  Alternatively, the container would need to process
the compiler's message, pick out the reported offending line number, and
tie that back to JSP source.  (I actually believe that some JSP containers
do this; it's really up to the implementation.)

JSP 1.3 will most likely incorporate some of the features offered by
JSR-045, which provides a formalized mechanism for mapping Java source
lines to the code from secondary languages (like JSP) used to generate
Java source.  This will help debugging but doesn't directly address
compile-time errors.

In general, the Java code that's generated to handle JSP actions consist
simply of boilerplate calls to tag logic; they don't typically lead to
compile-time errors in the Java source.  Most compile-time errors come
from scriptlets.  Diminishing the use of scriptlets -- in favor of tags
and JSTL 1.0/JSP 1.3-style EL expressions -- can improve error reporting
substantially.  For instance, in the JSR-152 expert group's code base,
where we've integrated JSTL-style expressions into Tomcat directly, you
get error messages with the *JSP* column and line number for invalid
expressions like "${foo?!}".  A similar scripting expression, like "<%=
foo?! %>", would generally lead to a less helpful error message.

-- 
Shawn Bayern
"JSP Standard Tag Library"   http://www.jstlbook.com
(coming this summer from Manning Publications)

On Wed, 8 May 2002, Morris Hirsch wrote:

> Tags generate java code, which if all goes well we never need to see.
> 
> If all does not go well, we get error messages in terms of that code,
> and could understand them better if we did see the code,
> or perhaps better yet, if an error was related to the tag.
> 
> A trace utility could do that if every snip of generated code
>  was clearly linked to the tag it came from.  When lex and yacc
> generate C code, they keep track of the original line numbers,
> and pass them along as special comments in the C code.
> 
> Would this be helpful in JSP?
> 
> thanks for any thoughts on this,
> 
> Morris Hirsch
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>