Struts秘籍之第2段：第3.6式： 从图像提交表单

第3.6式. 从图像提交表单

问题

你想要使用户能够通过点击一个不在HTML表单标签中的图像来提交表单。

动作要领

适应一个对JavaScript URL 的链接来提交表单：

<html:link href="javascript:document.myform.submit(  )">
    <html:img page="/submit-form.gif" 
               alt="Submit" border="0"/> 
</html:link>

动作变化

Web 应用经常使用可点击的图像来提交表单而不是仅仅通过表单按钮。Struts 的html:image标签可以用来产生一个显示图像的HTML input type="image" 标签。但是，对于复杂的 HTML 布局，并不总是能够将图像嵌入在表单<form> . . . </form>标签之中。有些时候，一个 HTML 页面可能在页面的某一段可能有多个表单，而提交页面的图像则在页面的另一个区域。比如，工具条风格的图像按钮。

上面的方法可以用于从表单之外的图像提交表单。所显示的图像嵌套在html:link标签中。该链接通过执行一行JavaScript来提交表单。在上面的代码中，JavaScript 将提交名为MyForm 的表单。表单名称必须匹配struts-config.xml文件中所配置的action元素的name属性。下面是这种方法产生的HTML 代码：

<a href="javascript:document.myform.submit(  )">
    <img src="/myapp/struts-power.gif"
         border="0" alt="Submit">
</a>

虽然你可以直接使用上述HTML标记而不是Struts html标签，如果那样的话你将失去那些标签所提供的特征。通过使用Struts tag，你就不是必须要指定context 名称，并且你可以使图像名称和替换文本来自于资源束 (如果你需要的话)。

另一个办法是使用html:img 标签的onclick属性：

<html:img page="/submit-form.gif"
       onclick="document.MyForm.submit( );"
           alt="Submit" border="0"/>

这种方式的缺点是，有些浏览器并不提供图像是可以点击的一些可视提示线索。因为图像嵌入到一个链接中，大多数浏览器都会在改变鼠标指针以提示该图像是可以点击的。

相关招式

第3.9式会描述如何在表单的action属性中指定的地方将表单提交到另外一个URL。

Struts秘籍之第2段：第3.5式： 在JSTL循环中使用索引属性

第3.5式. 在JSTL循环中使用索引属性

问题

你想要在在JSTL c:forEach循环而不是Struts logic:iterate循环中通过Struts html标签使用索引属性。

动作要领

为了创建一个简单索引属性的字段，可使用bean:define标签将循环计数暴露为一个可用于运行时表达式的脚本变量：

<c:forEach var="theItem" items="${MyForm.myItems}" varStatus="loopStatus">
  <bean:define id="itemIndex">
    <c:out value="${loopStatus.index}"/>
  </bean:define>
  <br/><html:text property='<%="myItem["+itemIndex+"]"%>'/>
</c:forEach>

如果索引属性是一个嵌套的bean 并且你使用的是indexed="true" 属性，那么可以将Struts logic:iterate标签替换为JSTL c:forEach:

<c:forEach var="theNestedItem" items="${MyForm.myNestedItems}">
  <br/><html:text name="theNestedItem" 
              property="nestedProperty"
              indexed="true"/>
</c:forEach>

动作变化

JSTL的c:forEach标签提供了一些额外的功能并且比logic:iterate更加易用。需要循环遍历的条目可以通过使用EL来指定。JSTL 标签允许对集合的子集上进行更多的控制，并且循环状态的细节也很容易获得。然而，如同所有JSTL标签一样，没有脚本变量被创建。我们在其他招式中所过，在处理索引属性时，不得不使用脚本变量。特别是如果你没有使用struts-el标签库更是如此。

bean:define标签从JSTL创建的范围变量中创建一个基本变量。这个bean:define标签基于取自value属性或者标签体的值创建了一个新的范围变量和对应的脚本变量。后一种方式在JSTL和Struts标签之间建立了一个桥。在这一招中，bean:define标签用于创建一个包含可用于访问索引属性的索引的变量。你可以在第3.4式中的选择喜好颜色的标但中使用这种技术。

What are your three favorite colors:
<c:forEach var="theColor" items="${FavoritesForm.color}"
     varStatus="loopStatus">
    <bean:define id="ctr">
        <c:out value="${loopStatus.index}"/>
    </bean:define>
    <br/><html:text property='<%="color["+ctr+"]"%>'/>
</c:forEach>

根据第3.4式，你可以使用Struts-El标签来消除scriptlet：

What are your three favorite colors:
<c:forEach var="theColor" items="${FavoritesForm.color}" 
varStatus="loopStatus">
  <br/><html-el:text property='color[${ctr}]'/>
</c:forEach>

如果需要为一个对象的嵌套属性创建一个HTML 输入字段，而该对象是一个索引属性，那么请在Struts html 标签中指定indexed="true" 属性。indexed属性的用法在使用JSTL c:forEach循环和使用logic:iterate循环时是一样的。下面是这种技术如何使用在第3.4式中的表单的喜好链接部分：

What are your favorite links?
<table>
    <tr>
        <th>Name</th>
        <th>URL</th>
    </tr>
    <c:forEach var="webLink" items="${FavoritesForm.webLinks}">
        <tr>
            <td>
                <html:text name="webLink" 
                       property="name" indexed="true"/>
            </td>
            <td>
                <html:text name="webLink" 
                       property="url" indexed="true"/>
            </td>
        </tr>
    </c:forEach>
</table>

渲染后的索引值被正确产生，哪怕是使用了begin, end, 和step属性来控制循环。下面的c:forEach用法演示了如何为集合的第1个和第3个元素产生输入字段：

<c:forEach var="webLink" items="${FavoritesForm.webLinks}"
         begin="1" end="3" step="2">
    <tr>
        <td>
            <html:text name="webLink" property="name" indexed="true"/>
        </td>
        <td>
            <html:text name="webLink" property="url" indexed="true"/>
        </td>
    </tr>
</c:forEach>

这将产生下面的HTML:

<tr>
    <td><input type="text" name="webLink[1].name" value=""></td>
    <td><input type="text" name="webLink[1].url" value=""></td>
</tr>
         
<tr>
    <td><input type="text" name="webLink[3].name" value=""></td>
    <td><input type="text" name="webLink[3].url" value=""></td>
</tr>

为了在循环中渲染动态数据以供显示，JSTL 工作的很好，并且比对赢得Struts 标签更易使用。你可以看到，JSTL 在访问索引属性方面比Struts 标签支持的更好。例如，下面的代码就展示了喜好颜色可以如何显示：

<c:forEach var="color" items="${favs.color}">
    <li><c:out value="${color}"/></li>
</c:forEach>

相关招式

第3.4式演示了索引属性的类似用法。

你可以参考JSTL 的相关文档和信息，以及书籍。JSTL规范参见http://java.sun.com/jsp/jstl.

Struts秘籍之第2段：第3.4式：在表单中使用索引属性

     摘要:   第3.4式. 在表单中使用索引属性 问题 你想要在表单中创建对应于一个Bean中的索引属性的一套输入字段。 动作要领 在Struts html标签库的标签中使用indexed属性来产生属性值：   <html:form action="TestOneAction"><p>  <logic:iter...  阅读全文

Struts相关资源

Apache Struts Web Framework官方网站

http://struts.apache.org

Apache Struts Web Framework示例应用和实际应用

1.         SF上的一个Apache Struts 示例应用集

http://struts.sourceforge.net/

其中包括一些很著名和很有用的项目。主要有：

n         AppFuse – 一个非常著名的，优秀的基线示例应用，并扩展到使用多种框架。 其官方网站是：https://appfuse.dev.java.net/ 作者Matt Raible网站是：http://raibledesigns.com/wiki/Wiki.jsp?page=Main 他是Spring Live的作者，也是Apache Struts Web Framework Resume和StrutsMenu的作者

n         Polls – 一个在线调查管理的Apache Struts Web Framework 应用。

n         Struts k Action Invocation Framework (SAIF) – 为Apache Struts 添加动作拦截器和IoC特征。

n        Struts  BSF – 一个使用BSF 兼容脚本语言的 Apache Struts  Action 实现。

n        Struts Cocoon – 集成Apache Struts  和Cocoon，使用Cocoon 作为表现层。

n        Struts  Flow – 将Cocoon的控制流带入Apache Struts  中

n       Struts  Resume – Appfuse作者的一个例子，使用AppFuse 作为基础。参见：http://raibledesigns.com/wiki/Wiki.jsp?page=StrutsResume

n         Struts  Spring – 集成Apache Struts 和Spring 框架的集成库。

n         StrutsDoc – 一个用于 Struts或者 Struts 相关配置文件的JavaDoc风格的文档工具。

n         AjaxTags – 添加了AJAX功能的 Struts  HTML taglib 的修改版本。

该项目的下载列表中还包括其他一些有用的东西，主要有：

n         artimus   Struts  in action作者编写，并在书中分析提及的一个应用。

n     Struts  in Aciton 书籍的源代码

n         Struts  CookBook

2         Apache Struts Web Framework Menu  也是Matt Raible 的作品，http://sourceforge.net/projects/struts-menu/

3         XPlanner 一个基于Web的项目计划跟踪工具。JSP+Struts+Velocity+Mysql+Tomcat. http://www.xplanner.org/

4         STXX   Apache Struts Web Framework中通过XSL进行XML变换 http://stxx.sourceforge.net/

5         Liferay 著名的开源Java门户系统， 使用Apache Struts Web Framework作为前端 http://www.liferay.com

6          

开发工具

1.       Borland JBuilder

2.       IBM Rational Application Developer

3.       Oracle Jdeveloper

4.       BEA Weblogic Workshop

5.       Myeclipse

6.       M7 Nitrox Apache Struts Web Framework IDE

7.       Easy Apache Struts Web Framework, For Eclipse and JB

8.       Apache Struts Web Framework Console

9.       Exadel Studio

其他资源

1.        Strust in Action的作者的资料 http://www.husted.com/struts/ 。其实有这个网站，我这个列表也显得多余。那就增加一些中文的内容好了。本网站还包括很多Java相关的资源链接。

2.        Apache Struts Web Framework官方资源站点 http://wiki.apache.org/struts/StrutsResources

3.        国内主要的Apache Struts Web Framework技术论坛

n         http://www.chinajavaworld.com/

n         http://www.cjsdn.net

n         http://www.matrix.com

n         http://forum.javaeye.com/

书籍（其中红色部分有中文版）

•     Jakarta Apache Struts Web Framework Cookbook  Bill Siggelkow (February 2005)
•        Jakarta Apache Struts Web Framework Pocket Reference by Chuck Cavaness, Brian Keeton (June 2003)
•        Programming Jakarta Apache Struts Web Framework by Chuck Cavaness (November 2002)
•        Professional Jakarta Apache Struts Web Framework by James Goodwill, Richard Hightower (September 2003)
•          Apache Struts Web Framework Survival Guide: Basics to Best Practices by Srikanth Shenoy, Nithin Mallya (February 2004)  下载该书的电子版 点击这里
•          Apache Struts Web Framework In Action by Ted Husted, Cedric Dumoulin, George Franciscus, and David Winterfeldt; Foreword by Craig R. McClanahan (November 2002)  网上可以搜索到我翻译的中文版电子书。
•          Apache Struts Web Framework Kick Start by James Turner, Kevin Bedell (December 2002)
•          Mastering Jakarta Apache Struts Web Framework by James Goodwill (September 2002)
•          Apache Struts Web Framework: The complete reference by James Holmes (April 2004)
•          Professional Apache Struts Web Framework Applications: Building Web Sites with Apache Struts Web Framework, Object Relational Bridge, Lucene, and Velocity by John Carnell, Jeff Linwood (March 2003)
•          The Apache Struts Web Framework Framework: Practical Guide for Java Programmers by Sue Spielman (October 2002)
•          Pro Jakarta Apache Struts Web Framework, Second Edition by John Carnell, Rob Harrop (March 2004)
•       Struts  Recipes by George Franciscus, Danilo Gurovick (July 2004)
•          Apache Struts Web Framework Fast Track: J2EE/JSP Framework: Practical Application with Database Access and Apache Struts Web Framework Extension] by Vic Cekvenich - Sept. 2001 (1st Apache Struts Web Framework Book)
•          Apache Struts Web Framework by James Turner, Kevin Bedell (June 2003)

Web和Services, 能混为一谈吗？

以下是Ted Neward的一个blog，旨在陈清多年来一直可能混淆的概念，即“Web Services”是一个东西吗？
他认为,其实人们可能都混淆了，Web代表的是互操作性，而Services则是代表一种设计理念，即独立的、自治的、无耦合的组件模型。而“Web Service”仅是其中的一种结合方案而已。
颇有见地。
下面是摘录的原文，其中精彩之处予以标出：原文可访问 http://www.neward.net/ted/weblog/index.jsp?date=20050525#1117011754831

Web + Services

A lot has been written recently about Service-Orientation and Web services and REST and the massive amounts of confusion that seem to be surrounding the whole subject. After much navel-contemplation, I'm convinced that the root of the problem is that there's two entirely orthogonal concepts that are being tangled up together, and that we need to tease them apart if we're to make any sense whatsoever out of the whole mess. (And it's necessary, I think, to make sense out of it, or else we're going to find ourselves making a LOT of bad decisions that will come to haunt us over the next five to ten years.)

The gist of the idea is simple: that in the term "Web services", there are two basic concepts we keep mixing up and confusing. "Web", meaning interoperability across languages, tools and platforms, and "services", meaning a design philosophy seeking to correct for the flaws we've discovered with distributed objects and components. These two ideas, while definitely complementary, stand alone, and a quick examination of each reveals this.

Interoperability, as an idea, only requires that programs be written with an eye towards doing things that don't exclude any one platform, tool or technology from playing on the playground with the other kids. For example, interoperability is easy if we use text-based protocols, since everybody knows how to read and write text; hence, HTTP and SMTP and POP3 are highly-interoperable protocols, but DCOM's MEOW or Java's JRMP protocols aren't, since each relies on sending binary little-endian or big-endian-encoded data. Interoperability isn't necessarily a hard thing to achieve, but it requires an attention to low-level detail that most developers want to avoid. (This desire to avoid low-level details isn't a criticism--it's our ability to avoid that kind of detail that allows us to write larger- and larger-scale systems in the first place.)

This "seeking to avoid exclusion" requirement for interoperability is why we like using XML so much. Not only is it rooted in plain-text encoding, which makes it relatively easy to pass around multiple platforms, but its ubiquity makes it something that we can reasonably expect to be easily consumed in any given language or platform. Coupled with recent additions to build higher-order constructs on top of XML, we have a pretty good way of representing data elements in a way that lots of platforms can consume. Does interoperability require XML to work? Of course not. We've managed for the better part of forty years to interoperate without XML, and we probably could have kept on doing quite well without it; XML makes things easier, nothing more.

Services, on the other hand, is a design philosophy that seeks to correct for the major failures in distributed object and distributed component design. It's an attempt to create "things" that are more reliable to outages, more secure, and more easily versioned and evolvable, things that objects/components never really addressed or solved.

For example, building services to be autonomous (as per the "Second Tenet of Service-Orientation", as coined by Mr. Box) means that the service has to recognize that it stands alone, and minimize its dependencies on other "things" where possible. Too much dependency in distributed object systems meant that if any one cog in the machine were to go out for some reason, the entire thing came grinding to a halt, a particularly wasteful exercise when over three-quarters of the rest of the code really had nothing to do with the cog that failed. But, because everything was synchronous RPC client/server calls, one piece down somewhere on the back-end meant the whole e-commerce front-end system comes to a shuddering, screeching pause while we figure out why the logging system can't write any more log messages to disk.

Or, as another example, the First Tenet states that "Boundaries are explicit"; this is a well-recognized flaw with any distributed system, as documented back in 1993 by Wolrath and Waldo in their paper "A Note on Distributed Computing". Thanks to the fact that traversing across the network is an expensive and potentially error-prone action, past attempts to abstract away the details of the network ("Just pretend it's a local call") eventually result in nothing but abject failure. Performance failure, scalability failure, data failure, you name it, they're all consequences of treating distributed communication as local. It's enough to draw the conclusion "well-designed distributed objects are just a contradiction in terms".

There's obviously more that can be said of both the "Web" angle as well as the "Services" angle, but hopefully enough is here to recognize the distinction between the two. We have a long ways to go with both ideas, by the way. Interoperability isn't finished just because we have XML, and clearly questions still loom with respect to services, such as the appropriate granularity of a service, and so on. Work remains. Moreover, the larger question still looms: if there is distinction between them, why bring them together into the same space? And the short answer is, "Because individually, each are interesting; collectively, they represent a powerful means for designing future systems." By combining interoperability with services, we create "things" that can effectively stand alone for the forseeable future.

And in the end, isn't that what we're supposed to be doing?