第3.7式. 动态产生JavaScript
问题
你想要根据从应用模型获得的数据动态产生JavaScript。
动作要领
使用Struts 标签在你想要包含在HTML中的JavaScript 代码中渲染数据：
<script language="JavaScript">
function showMessage( ) {
alert( "Hello, <bean:write name='myForm' property='name'/>!" );
}
</script>
动作变化
上述方案产生了一个JavaScript 函数，弹出一个消息框，消息文本为"Hello, name!" name的值是使用bean:write标签产生的。此方案展示了使用Struts 标签创建JavaScript 和它们创建HTML一样的容易。
JSTL也可以按这种方式使用。
虽然这种方法很明显，但是很奇怪很多人都在问这个问题。通常问题还可能是："我如何才能从Struts中调用HTML中的JavaScript 函数？" 技术上讲，你并不能从Struts调用一个HTML页面中的JavaScript 函数。Struts 和JSP 技术都运行在服务器端。相反，JavaScript确是在客户端的浏览器中处理的。但是，通过这里所述的动态产生JS的能力，基本上还是相当于所需的这个行为。
这个方法的一个重要基础是JSP的转换过程。JSP 页面由JSP 声明，标准JSP 标签 (比如jsp:useBean), 定制JSP 标签(比如Struts 和JSTP 标签), 运行是表达式，以及脚本小程序（scriptlets）组成。除此之外的其他东西都是模板文本（template text）。模板文本可以是任何不会被JSP转换处理的内容。人们通常会认为模板文本就是HTML 标记，但是它其实是JavaScript 或者其他非JSP 处理的文本。JSP 翻译器并不关心模板文本采用何种形式。因此，你可以象在HTML元素中产生文本一样容易地在JavaScript 函数中产生文本。
如果你使用JSP 来产生良构的（well-formed）XHTML, 那么动态JavaScript 模版文本必须使用jsp:text元素和CDATA section的方式结合来指定。具体信息参见Hans Bergsten的ONJava 文章：http://www.onjava.com/pub/a/onjava/2004/04/21/JSP2part3.html。
这里的例子仅仅列出了很简单的使用场景。如果要访问的模型数据需要使用复杂的JavaScript数据结构，比如，数组，你可以使用迭代标签，比如logic:iterate和c:forEach来组装这些结构。
相关动作
下一动3.8或会使用迭代标签来产生客户端的JavaScript 数组。
看到JavaLobby上面有篇比较JSF和ASP的文章：
Is JSF ready to take on ASP.Net?
总体来看 JSF逐渐在使Java开发向着更加RAD的方向发展，JB, Oracle Jdeveloper, IBM WSAD/RAD， SUN JSF Creator等等都作的不错，提供了一定的visual可视化组件开发的能力和数据帮定能力。但是距离MS的可用性还是相差甚远。
尤其是VS.NET 2005一出之后，这个差距更大更需要努力了。
JSF预计出现的第3方组件市场并没有出现蓬勃发展，是因为JSF本身没有起来，还是IDE不够标准。可能两者都有，特别是后者，规范中并没有界定组件需要IDE支持，必须提供的元数据集合，那么到底是针对oracle呢，还是IBM?或者自行其是。
Struts继续占据着前端框架的霸主地位，WebWork和Tapstry艰难求生。连Spring也将触角伸到前端。JSF还是困难啊。
Matte Railbe的BLog中有一个关于框架的发展现状：
去年闹着玩的《Struts in Action》译本，想不到网上流传的还是比较广泛了。不过去年草稿发出后，再也没有修改过了。前
几天翻出来看，倒是有不少错误，包括错别字和翻译错误。
觉得这样很不好，搞不好误人子弟。于是决定近日将其重新修改整理，发一个完整半出来。
感兴趣的，可以关注我这里的相关信息。我将在这里提供下载链接。
JDJ上面有一篇 Duncan Mills 的文章，论述了框架技术的下一个发展，那就是Java世界需要一个元框架（Meta-Framework）。原文地址见：
http://java.sys-con.com/read/49198.htm
他认为，.NET之所以也很成功并且吸引很多人，总体来说，.net的技术成本要低的多（当然商业成本不低），这是因为.Net环境下有一个集成的统一框架，而java世界，则疲于整合各种JSR，各种技术，各种实现和各种框架。从Struts，WebWork, Tapstry, Hibernate, Spring, Keel....框架层出不穷。我们比较、学习、整合.....累啊。
因此，一个元框架的出现，应该符合以下的特征：
- 范围广阔（Broad Scope） 框架应该涵盖从UI，到页面流控制器，到与多个底层服务 provider的集成，包括EJB, Web services, POJO...。
- 并存（Coexistence） - 框架不能实现所有需要的功能，但是能够提供可插入的集成点。
- 抽象（Abstraction） -足够抽象，并且你可以选择。以便能够对某些组件的具体实现进行替换。
- 呵呵， 还有长寿（Longevity
- 工具支持（Tooling）
这其中最流行的是什么？POJO，IoC/DIP？想想， 重量级的EJB3.0能否重整雄风？而轻量的Spring已经繁花似锦。另外， JSF整合了JSP, JSTL和Portel API之后，能否成为前端的标准？毕竟标准的事件模型还是令人鼓舞的，而且，浏览器的兼容问题也好解决一些。这些都有可能成为metaFramework的候选。
Oracle的ADF已经从ADF UIX迁移到JSF，这下厉害了。ADF(JSF+bizmodule)+TOPLINK， 是否有能够和 SPring + Hibernate有的一拼呢？
另外，Keel是否显得比较乱？
而 NetKernel 呢？
看到XML.com一篇关于XForms引擎的评述，
地址是：
http://www.xml.com/pub/a/2005/02/09/xforms.html
-
Chibacon Chiba
-
DENG by way of UGO
-
x-port formsPlayer
-
Mozilla/Firefox
-
Novell Engines
-
OpenOffice and StarOffice
-
Oracle Engine
-
Orbeon Presentation Server (OIS)
-
Zen Interactif xslt2xforms
-
University of Helsinki X-Smiles
-
Honorable Mention: Ripcord Technology nForms