java - 为什么 scriptlet 存在于 JSP 中？

Question

关于在 JSP 中使用 Scriptlet(那些类似于 php 的 <% %> 东西)是多么可怕，我已经听过十亿 次了。

• 事实证明，Scriptlet 打破了代码设计模式，而且通常是 MVC Pattern
• 许多 J2EE 框架(例如 JSF 2.0+ )已经禁止使用 scriptlet。

既然 scriptlet 不需要任何用途，可以用 JSTL、Other taglibs 和 EL(表达式语言)代替，为什么它们仍然存在？为什么 Oracle 还没有从 JSP 技术中删除这些 scriptlet？

Answer 1

这是一个三年前的问题，但我想谈谈我对此事的个人看法。我在大型项目(CRM 系统)中使用带有 scriptlet 的 JSP 超过 15 年，以下是我的经验:

• 只有在您允许的情况下，Scriptlet 才会破坏 MVC 模式。我不明白为什么应该是 <c:out ...${product.priceVat}>不知何故更好<%= product.getPriceVat() %> .很多时候它实际上更糟。它更冗长，您可能会丢失类型信息。是属性(property)priceVat BigDecimal 还是带货币的格式化字符串？您有时不知道 EL(取决于使用的 IDE)。
• 自动化重构对我们的项目有很大帮助。如果一位开发人员重命名 getPriceVat getPriceTax 的方法它必须反射(reflect)在所有代码库中。 IntelliJ IDEA 非常擅长处理小脚本。不确定它是否会自动重命名 ${product.priceVat}至 ${product.priceTax} (编辑:确实如此，很酷)。 Netbeans 或 Eclipse 不能很好地处理 JSP sefactorings。
• Scriptlet 的性能优于 EL/JSTL 组合。如果您深入了解，他们必须这样做。后者产生更大的代码 (Apache Jasper)，我们在 64kB 的代码限制下运行了几次 Java 方法，实际上被迫用 scriptlet 替换了一些标签。
• 原型(prototype)设计。我们经常使用 scriptlet 制作 JSP 原型(prototype)(键入代码 - 刷新页面 - 键入代码 - 刷新...)。稍后我们会增强我们的标签库并清理页面。
• 热修复。我们通过直接更改生产服务器上的一个 JSP scriptlet 来防止服务器重启几次。如果您需要更改类内部的已编译代码并需要重建整个 WAR 文件，则这是不可能的。我知道这很讨厌。
• 代码缩进是 scriptlet 的噩梦。这是使用 Scriptlet 的明显缺点。
• 我希望对 scriptlet 的支持永远不会被弃用。在 web.xml 中禁用 scriptlet 的功能对于干净的代码纯粹主义者来说应该足够好了。