Reputation: 473
I've been trying to understand BalusC's answer with regard to debuggability, and I still cannot figure out exactly how jstl tags are more easily debugged than scriptlets.
When I think of debugging, I think of the ability to step through the code and determine at any given point what variables are loaded into memory, and see their contents. With jstl, I cannot set up breakpoints of any kind, and if any part of it breaks, pieces of whatever form I'm working on go missing. I'm not sure which is worse: a blank page, or a half-loaded page. I've seen situations where when the jstl fails, OTHER parts of the form go missing rather than only the parts it affects. In either case, it's impossible to really see what the problem is.
With scriptlets, I can place breakpoints, and see any point I'd like in an IDE. Even if I'm not using such a feature, I can print to the console any part of the procedure I want to see and figure it out later. If the page fails and shows me a blank page, annoying as that may be, I can at least step through and find out exactly which line it fails on.
With jstl, I'm completely in the dark. Iterating through a collection really feels like a black box where you hope everything comes out ok rather than actually being able to step through and watch it happen. It makes you feel powerless.
I admit, jstl is cleaner, and looks more intuitive, but that one glaring problem I have is the inability to really debug anything on the page. Am I completely mistaken here? Am I just missing the nice happy way to debug what's going on? Or is my approach to debugging incorrect, and in need of rethinking?
I've googled the issue, but I can't really seem to come up with any direct answers... If anyone has any insight on this, it would be really helpful. I want to use jstl in lieu of scriptlets, and this is the one glaring thing keeping me back...
Upvotes: 3
Views: 12675
Reputation: 59
You can add jsp scriptlets and print the variables jstl uses. This gets printed in the console or in the container's out file
<c:set var="myVar" value='${param.myUrlParam}' />
<% System.out.println(pageContext.findAttribute("myVar") ); %>
This is the only best way I could find to debug a jstl page.
Upvotes: 4
Reputation: 1109874
JSTL tags themselves doesn't need to be debugged if you use them conform the JSP/EL specification and JSTL documentation. In the answer which you found, the "debuggability" is merely meant in context of Java code for business logic which needs to be replaced by a Java class like a servlet, filter, entity or EJB, not Java code for presentation logic which needs to be replaced by JSTL tags like if/else
blocks, for
loops, HTML escaping, date/number formatting, string manipulation functions, etc.
However, if you face a problem for which you've tracked down the root cause to apparently the JSTL tags, then re-read the JSTL documentation if you used them properly. You can also just do a dump of EL variables of interest using the following template:
<h2>Request headers</h2>
<dl>
<c:forEach items="${headerValues}" var="entry">
<dt><c:out value="${entry.key}" /></dt>
<dd>
<c:forEach items="${entry.value}" var="headerValue" varStatus="loop">
<c:out value="${headerValue}" />${not loop.last ? ', ' : ''}
</c:forEach>
</dd>
</c:forEach>
</dl>
<h2>Request params</h2>
<dl>
<c:forEach items="${paramValues}" var="entry">
<dt><c:out value="${entry.key}" /></dt>
<dd>
<c:forEach items="${entry.value}" var="paramValue" varStatus="loop">
<c:out value="${paramValue}" />${not loop.last ? ', ' : ''}
</c:forEach>
</dd>
</c:forEach>
</dl>
<h2>Request scope</h2>
<dl>
<c:forEach items="${requestScope}" var="entry">
<dt><c:out value="${entry.key}" /></dt>
<dd><c:out value="${entry.value}" /></dd>
</c:forEach>
</dl>
<h2>Session scope</h2>
<dl>
<c:forEach items="${sessionScope}" var="entry">
<dt><c:out value="${entry.key}" /></dt>
<dd><c:out value="${entry.value}" /></dd>
</c:forEach>
</dl>
<h2>Application scope</h2>
<dl>
<c:forEach items="${applicationScope}" var="entry">
<dt><c:out value="${entry.key}" /></dt>
<dd><c:out value="${entry.value}" /></dd>
</c:forEach>
</dl>
You could if necessary wrap it in some popup panel which is opened via an access key and only rendered during development mode (the Java EE's MVC framework JSF has a much similar thing in flavor of <ui:debug>
).
If in vain, naildown the problem into the smallest possible JSP file which reproduces the whole problem by just copy'n'paste'n'running (in such example, you can put the necessary business logic and e.g. request.setAttribute()
lines in a scriptlet which is been placed in very top of the JSP file; prototyping like that is one of legitimate use cases for a scriptlet).
If you still can't figure it out based on that SSCCE, post it as a question on Stack Overflow. When properly put, you'll likely get an answer in less than a day. Don't be surprised if it more than often boils down to a simple typo or a syntax/logic error.
Upvotes: 1