JSP is no longer required.

Freemarker（Velocity) VS Pure XLST 三者全是。

但你不能因为是XSLT就认为全否了啊。

XLST开发效率....

如你所说，XSLT的开发效率体现在两个方面：1。掌握的人不多；2。缺乏相应的工具。

针对这两个方面可以采取如下方法，1。培训；2。使用浏览器本身对XSLT的支持。

俺只需要一个美工，你却需要两个人，这要花钱吧？ 培训也要花钱吧？IE和FF对XLST支持不同要考虑吧？

另一条路而已....这样的探索是 少不了的.

贼个俺同意，探索是另一回事，business又是另一回事，年底了俺对花钱的事敏感。

就这个项目谈jsp is not required，还早。

三年前做过一个这样的项目，当时对XLS的认识完全是0，但是学习起来似乎也没有太高的难度。不当然由于是企业项目UI相对简单。
用XML存储数据在某些情况可以简化表的设计。

最重要的 10 几个J2EE 最佳实践第9条：将 JSP 作为表示层的首选。
只有在需要多种表示输出类型，并且输出类型被一个单一的控制器及后端支持时才使用 XML/XSLT。
我们常听到一些争论说，为什么您选择 XML/XSLT 而不是 JSP 作为表示层技术。选择 XML/XSLT 的人的观点是，JSP“ 允许您将模型和视图混合在一起”，而 XML/XSLT 不会有这种问题。遗憾的是，这种观点并不完全正确，或者至少不像白与黑那样分的清楚。实际上，XSL 和 XPath 是编程语言。XSL 是图灵完成的（Turing-complete），尽管它不符合大多数人定义的编程语言，因为它是基于规则的，并且不具备程序员习惯的控制工具。
现在的问题是既然给予了这种灵活性，开发人员就会利用这种灵活性。尽管每个人都认同 JSP 使开发人员容易在视图中加入“类似模型”的行为，而实际上，在 XSL 中也有可能做出一些同样的事情。尽管从 XSL 中进行访问数据库这样的事情会非常困难，但是我们曾经见到过一些异常复杂的 XSLT 样式表执行复杂的转换，这实际上是模型代码。

然而，应该选择 JSP 作为首选的表示技术的最基本的原因是，JSP 是现在支持最广泛的、也是最被广泛理解的 J2EE 视图技术。而随着自定义标记库、JSTL 和 JSP2.0 的新特性的引入，创建 JSP 变得更加容易，并且不需要任何 Java 代码，以及可以将模型和视图清晰的分离开。在一些开发环境中（如 WebSphere Studio）加入了对 JSP（包括对调试的支持）的强大支持，并且许多开发人员发现使用 JSP 进行开发要比使用 XLS 简单，一些支持 JSP 的图形设计工具及其他特征（尤其在 JSF 这样的框架下）使得开发人员可以以所见即所得的方式进行 JSP 的开发，而对于 XSL 有时不容易做到。

最后一个要谨慎考虑使用 JSP 的原因是速度问题。在 IBM 所作的对比 XSL 和 JSP 相对速度的性能测试显示：在大多数情况下，JSP 在生成同样的 HTML 的时候，要比 XSL 快好几倍，甚至使用编译过的 XSL 也是如此。尽管多数情况下这不是问题，但在性能要求很高的情况下，这就会成为问题。

然而，这也不能说，您永远也不要使用 XSL。在一些情况下，XSL 能够表示一组固定的数据，并且可以基于不同的样式表（请参见 [Fowler]）来以不同的方式显示这些数据的能力是显示视图的最佳解决方案。然而，这只是一种例外的情况，而不是通用的规则。如果您只是生成 HTML 来表达每一个页面，那么在大多数情况下，XSL 是一种不必要的技术，并且，它给您的开发人员所带来的问题远比它所能解决的问题多。

引自http://www.ibm.com/developerworks/cn/websphere/techjournal/0405_brown/0405_brown.html

从工程的角度来考虑，人员分工才是管理追求的目标，专业才能得以发挥，
从长远看，企业发展也需要这样的管理方式，哪个花钱多，就是智者见智了。

IE和FF的支持不同在那里都会碰到，这个。。。。。。