JSTL有哪些替代方案？

JSTL还有其他选择吗？我在3年前工作过的一家公司使用JSTL和自定义标记库将表示与逻辑分开.前端开发人员使用EL来执行复杂的表示逻辑,在JSP页面中生成布局,并且效果很好.也许新技术已经问世.这些天好不好？

JSTL和EL是两个截然不同的概念.

JSTL只是一个标记库.大多数框架都提供了自己的taglib,大致复制了JSTL的功能.我大致说,因为这些经常滥用或忽略JSP和Servlet API的关键原则.

JSTL的优势在于它是由JSP的作者设计的,对JSP和servlet有深刻的理解.第三方标签库通常由一些不想使用RTFM的人创建,并决定"从头开始"并提出"更简单的东西".但是,JSTL无意做任何事情.它可以非常成功地与其他标记库一起使用,包括您自己的自定义标记.

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

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

我很熟悉OGNL多年以前的WebWork经验,我对Struts2的最大失望是没能抛弃这个残骸.甚至WebWork的创始人Patrick Lightbody都承认采用是一个错误.*幸运的是,它只能在有限的环境中使用,比如OGNL感知标签(和其他一些令人惊讶的地方),不像EL,它由容器本身和可以在页面的任何地方使用.

如果你想远离JSP,但不是像JSF这样的基于组件的方法,你可以查看Terrence Parr的StringTemplate项目.重点是无副作用,这为安全性和可扩展性提供了有价值的改进.

*QFT:在成功攻击基于Struts2的Apple开发者网站之后,Patrick Lightbody说:"可悲的是,我对这个相当重要的安全漏洞感到有责任.有一些像这样的事情,它们都植根于这样一个事实:差不多9年前,我决定使用OGNL作为WebWork的表达语言.我之所以这么做是因为它"强大",但它打开了我从未想过的各种额外的绑定技巧."

我使用了速度非常成功,它作为一种将业务逻辑与表示逻辑分离的简单方法,效果很好.而且它很简单,您的普通Web开发人员可以理解它. Freemarker是许多人喜欢的另一种模板替代品.