有没有 JSTL 的替代品?我在 3 年前工作的一家公司使用 JSTL 和自定义标记库将表示与逻辑分开。前端开发人员使用 EL 来执行复杂的表示逻辑,在 JSP 页面中生成布局,效果很好。也许新技术已经问世。这几天有什么好点的吗?
6 回答
JSTL 和 EL 是两个不同的概念。
JSTL 只是一个标签库。大多数框架都提供自己的标记库,大致复制了 JSTL 的功能。我大致说一下,因为这些经常误用或忽略 JSP 和 Servlet API 的关键原则。
JSTL 的优势在于它是由 JSP 的作者设计的,对 JSP 和 servlet 有深入的了解。第三方标签库通常是由一些不想 RTFM 并决定“从头开始”并想出“更简单的东西”的人创建的。然而,JSTL 并不打算包揽一切。它可以非常成功地与其他标签库结合使用,包括您自己的自定义标签。
表达式语言是 JSP 的基础。它由容器解释,并且可以在许多情况下使用。它在很大程度上也没有副作用,并且具有简单、易于理解的语法,不允许将大量逻辑填充到表示层中。作为 Java EE 规范的一部分,它还享有广泛的工具支持。例如,当您重命名属性时,许多 IDE 可以重构依赖的 EL 表达式。
Struts2 将 OGNL 介绍给了更广泛的受众。OGNL 是对小脚本邪恶时代的回归。它更强大,因此开发人员乐于滥用它来调用表示层中的任意方法和其他暴行。攻击者也很乐意利用它;它是基于 Struts2 的应用程序中的常见漏洞来源。
我从以前使用 WebWork 的多年经验中熟悉 OGNL,而我对 Struts2 最大的失望是未能抛弃这个垃圾。甚至 WebWork 的创始人 Patrick Lightbody也承认采用是一个错误。*幸运的是,它只能在有限的上下文中使用,例如 OGNL 感知标签(以及其他一些令人惊讶的地方),这与容器本身支持的 EL 不同,并且可以在页面的任何地方使用。
如果您想摆脱 JSP,但不喜欢 JSF 这样的基于组件的方法,您可以查看 Terrence Parr 的StringTemplate项目。重点是无副作用,这为安全性和可扩展性提供了宝贵的改进。
* QFT:在成功攻击基于 Struts2 的 Apple Developer 网站后,Patrick Lightbody 说:“可悲的是,我对这个相当大的安全漏洞感到有些责任。有几个这样的,它们都植根于这样一个事实:大约 9 年前,我做了一个(错误的)决定,使用 OGNL 作为 WebWork 的表达语言。我这样做是因为它‘强大’,但它开启了各种我从未想过的额外绑定技巧。”
我已经非常成功地使用了速度,它作为一种将业务逻辑与表示逻辑分离的简单方法非常有效。而且它很简单,您的普通 Web 开发人员可以理解它。 Freemarker也是很多人喜欢的另一种模板替代品。
JSTL 是一个标签库,包含可在 JSP 页面中使用的逻辑函数。其他此类库也存在,但很可能您想查看整个 jsp/jstl 解决方案的修改方法。
最值得注意的是,我建议您查看:
阿帕奇检票口
带有 facelets 的 JSF
谷歌网络工具包 (GWT)
JSTL 鼓励您在 UI 中加入逻辑。尝试使用 Apache Wicket,而不是在 java 中完成逻辑。
假设您正在寻找一种使用 MVC 开发应用程序的更简单方法,我强烈建议您查看Spring Framework。Spring 有自己的标签库,它提供了 JSP 中您应该需要的大部分内容。我在使用 Spring webflow 和 Spring forms 标签库方面取得了巨大的成功。我喜欢将应用程序划分为持久层(使用 Spring 对 Hibernate 的 ORM 支持)、服务层(业务逻辑)和视图层。视图层包括用于验证和操作的 Web 流、JSP 和 POJO。我还在视图层中使用 DWR 进行 AJAX 调用。
我不会说它们是替代品或替代品,但我认为Java-Server-Faces在将表示与逻辑分离方面更进一步......