JSTL的替代品有哪些?

克里斯托弗·托卡(Christopher Tokar):

JSTL是否有替代品?我三年前工作过的一家公司使用JSTL和自定义标签库将表示与逻辑分离。前端开发人员使用EL进行复杂的表示逻辑,在JSP页面中生成布局,效果很好。也许已经出现了新技术。这些天有什么更好的吗?

埃里克森:

JSTL和EL是两个不同的概念。

JSTL只是一个标签库。大多数框架提供了自己的标记库,这些标记库近似复制了JSTL的功能。我大概说一下,因为这些经常会滥用或忽略JSP和Servlet API的关键原理。

JSTL的优势在于它是由JSP的作者设计的,对JSP和servlet具有扎实的理解。第三方标签库通常是由一些不想创建RTFM的人创建的,他们决定“从头开始”并提出“更简单的方法”。但是,JSTL并非打算做所有事情。它可以与其他标签库(包括您自己的自定义标签)一起非常成功地使用。

表达式语言是JSP的基础。它由容器解释,并且可以在许多上下文中使用。它在很大程度上也没有副作用,并且具有简单,易于理解的语法,不允许将大量逻辑塞入表示层。作为Java EE规范的一部分,它还享有广泛的工具支持。例如,重命名属性时,许多IDE都可以重构依赖的EL表达式。

Struts2向更广泛的受众介绍了OGNL。OGNL是对scriptlet邪恶时代的一种回归。它功能更强大,因此开发人员很乐意滥用它在表示层和其他暴行中调用任意方法。攻击者也乐于利用它。它是基于Struts2的应用程序中常见的漏洞

我从以前的WebWork经验中对OGNL很熟悉,而我对Struts2的最大失望是未能抛弃这个麻烦。甚至WebWork创始人Patrick Lightbody也承认采用是一个错误。*幸运的是,它只能在有限的上下文中使用,例如可识别OGNL的标签(以及一些其他令人惊讶的地方),这与EL不同,后者受容器本身和容器的支持。可以在页面的任何地方使用。

如果您想摆脱JSP的束缚,但又不喜欢JSF这样的基于组件的方法,则可以查看Terrence Parr的StringTemplate项目。重点是无副作用,这对安全性和可伸缩性进行了有价值的改进。

* QFT:在成功地攻击了基于Struts2的Apple Developer网站之后,Patrick Lightbody说:“可悲的是,我对这个相当大的安全漏洞负有责任。有一些类似的漏洞,它们都植根于以下事实:大约9年前,我做出了(糟糕的)决定将OGNL用作WebWork的表达语言。之所以这样做,是因为它“功能强大”,但却带来了我从未想过的各种额外的绑定技巧。”

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章