问题描述
我一直在试图了解关于可调试性，我仍然无法弄清楚jstl标签比scriptlet更容易调试。
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.
当我想到调试时，我想到了步骤的能力通过代码并确定在任何给定的点什么变量被加载到内存，并看到他们的内容。使用jstl，我不能设置任何类型的断点，如果它的任何部分断开，我正在工作的任何形式的部分都会丢失。我不知道哪一个更糟糕：一个空白页面或一个半页面的页面。我看到的情况是，当jstl失败时，表单的其他部分丢失，而不仅仅是它影响的部分。在任何一种情况下，都不可能真正看到问题是什么。
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.
使用scriptlet，我可以放置断点，并在IDE中看到我想要的任何一点。即使我没有使用这样的功能，我可以打印到控制台我想看到的任何部分的程序，并在以后计算出来。如果页面失败，并显示一个空白页面，可能会令人讨厌，我可以至少逐步了解哪个行失败了。
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.
使用jstl我完全在黑暗中通过一个集合迭代真的感觉像一个黑色的盒子，你希望一切都出来好了，而不是实际上能够通过并观察它发生。它让你感到无力。
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.
我承认，jstl更干净，看起来更直观，但是我遇到的一个明显的问题是无法真正调试页面上的任何内容。我完全错了吗我刚刚错过了很好的快乐方式来调试发生了什么？或者是我的调试方法不正确，需要重新思考？
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?
我已经尝试了这个问题，但我似乎无法想出任何直接的答案...如果有人对此有所了解，那将是非常有帮助的。我想使用jstl来代替scriptlet，这是一个让我很重要的事情。
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...
推荐答案
JSTL标签如果您使用它们符合和。在您发现的答案中，可调试性只是意味着需要由Java类（如servlet，过滤器，实体或EJB）替代的业务逻辑的Java代码，而不是需要使用表示逻辑的Java代码由 if / else 块，代替循环，HTML转义，日期/数字格式化，字符串操作等JSTL标记功能等。
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.
但是，如果您遇到了根本原因造成JSTL标记的问题，请重新阅读，如果您正确使用它们。您也可以使用以下模板进行感兴趣的EL变量的转储：
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>
如果需要，您可以将其包装在通过访问键打开并仅在开发模式（Java EE的MVC框架JSF与< ui：debug> 的风格非常相似）
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>).
如果徒劳无功，将问题解决成最小的JSP文件，通过复制复制整个问题，即可将所需的业务逻辑（例如 request.setAttribute（）在 scriptlet 中的行被放置在JSP文件的顶端;这样的原型就是一个合法的用例> scriptlet ）。
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).
如果您仍然无法根据该SSCCE计算出来，请将其作为Stack Overflow上的问题发布。妥善放置后，您可能会在不到一天的时间内得到答案。不要惊讶，如果它经常归结为简单的打字错误或语法/逻辑错误。
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.
这篇关于用jstl调试 - 怎么样？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！