JSTL与JSP Scriptlet

Question

我希望有人在这个问题中解释BlausC的惊人答案中的一些要点。

他说，脚本有一些缺点，它们是：

1. 可重用性:不能重用脚本。我的问题是:如何重用JSTL代码？
2. 可替换性:不能使脚本抽象。抽象意味着什么? JST是如何变得抽象的？
3. OO:你不能利用继承/组合。我如何在JSTL中使用OO范例？
4. 调试:如果脚本在中途抛出异常，所得到的只是一个空白页。
5. 可测试性:脚本不能进行单元测试。这意味着什么，以及如何对JSTL进行单元测试？
6. 可维护性:每个saldo都需要更多的时间来维护混合/混乱/重复的代码逻辑。这是什么意思？

最后一件事是他从Oracle的建议中引用的内容：

JSP脚本不应用于编写业务逻辑。

在MVC模式中，我只在表示层使用scriptlet。他在这里是什么意思？

Answer 1

您似乎只关注脚本的表示和流控制部分，比如在使用if、for和switch语句以及out.print()方面。您似乎将scriptlet 1:1与JSTL进行了比较。这是错误的。我所讨论的不仅仅是流控制部分(它确实将被JSTL所取代)，而是一般在JSP文件中编写原始Java代码。例如，收集请求参数、验证和转换值、与数据库和其他Java类/方法交互等等。所有您通常(间接)在Servlet或过滤器中做的事情。

Answer 2

在JSP中不应该有scriptlet代码。我建议100%的JSTL和零抄写代码。

联署材料应该是纯粹的陈述。这是仅使用JSTL编写JSP的潜在好处，因为它们从其他地方获取所有的动态数据。让服务层具有业务逻辑，并确定JSP需要哪些数据。

这也回答了您的单元测试问题。您不必对JSP进行单元测试；这将是类似Selenium的UI测试。如果逻辑位于服务层，那么测试它的方式是显而易见的。

联合来文不应继承。当然，您可以使用类似于SiteMesh的东西将它们组合在一起，但是继承在JSP中没有任何作用。一旦它们从Servlet继承，那么链就应该结束。

另外，这是个错误的选择。任何人都不应要求重用、继承或单元测试。但这并不意味着没有明确的赢家:它是JSTL。除了非常罕见的一行程序之外，没有人应该在JSP中使用scriptlet。斯克里特人在讨好麻烦。

这些天来，我更喜欢作为Java的web模板解决方案，而不是JSP。这只是我的观点。

Answer 3

我不能代表BalusC说话，但总的来说，我相信他认为这类事情应该由您的普通Java代码来完成(如果您对MVC有兴趣的话，在Controller和Model中)。

1. 您不能在单个级别上真正重用JSP标记，但您可以重用它们调用的类。
2. JSTL不能是抽象的，但是普通的Java代码(您也许可以从JSTL调用)可以是抽象的。
3. 同样，您不能在jstl中有效地创建对象，但是可以在调用的所有类中创建对象。
4. JSTL本身并不是可测试的单元。但是您通过它调用的类和方法是。