关注WebWork（四）
时间过得很快，《WebWork In Action》第三章的翻译工作也接近尾声了。这一章的标题是Setting up WebWork，主要讲述了与WebWork紧密相关的配置以及如何运用这些配置让我们的应用程序组织得更为模块化，让我们在设计上可以更加灵活机动。
在这一章中，我了解到了很多之前并不熟悉的配置，而这些配置所带来的影响，我不得不为之赞叹。以action为例，通常我们会根据逻辑来划分action，譬如Login、Register、Search和Logout等等，这些从逻辑语义上独立的部分都应该分别作为一个action，这一点是大家都认可的。在以上这些action的周边仍然会有一些其他附属功能，譬如在Login之前需要做的准备工作——PreLogin；在Search之后需要作进一步搜索的SearchMore。在面对这样的功能时候，你或许会将它们独立出来，作为一个新的action，同时也有可能想着将这些功能放到主逻辑功能当中去。如果你选择了后者，然后兴冲冲地打开IDE想往里面加方法的时候，或许你会犯愁了：方法加了进去，该在哪里调用呢？因为在应用程序运行的时候，WebWork框架只会调用继承的execute方法，那么自己加进去的方法呢？难道真的要在execute中调用？这不是又跟其他功能扯上关系了嘛？不要着急，且听我慢慢说来。
其实，以上说了那么多，只是想为大家勾勒一个应用场景而已。撇开那些复杂的场景不谈，需要解决的问题实际就是：如果让框架调用execute以外的方法。了解WebWork的您应该都十分了解：我们通常所写的action都会extend了ActionSupport类并且需要提供一个override的execute方法，然后在收到请求之后，WebWork框架会将请求分派给不同的action，由action的execute方法来处理这个请求。这就是框架所带来的好处：更加有序地组织代码；同时这也是一个限制。框架都会在限制与功能之间寻找一个平衡点，一个好的框架则会将这对矛盾处理得很好：有一定程度的限制，又不失灵活和强大功能，而WebWork就是这样一个框架。正当你为无法调用execute以外的方法而懊恼的时候，你会惊喜地发现WebWork提供了一种灵活的方式，让你只需修改一下配置文件就可以调用action中execute以外的方法，这样就不需要为一些主逻辑的周边功能而创建新的action类了，让你在设计的时候有更多的选择。要实现框架调用action中execute以外的方法，只需要设置好action节点的method属性即可。如以下例子所示：
<action name="Login" class="com.fantasysoft.Login">
<result name="success">userProfile.jspresult>
<result name="input">login.jspresult>
action>
<action name="PreLogin" class="com.fantasysoft.Login" method="preLogin">
<result name="success">login.jspresult>
<result name="error">error.jspresult>
action>
以上例子中名为PreLogin的action节点配置就会调用Login action中的preLogin方法，而不是常见的execute方法了。这里还有一个十分灵活的地方需要注意的，如果preLogin方法找不到的话，WebWork并不会马上抛出Exception，而是进而查找doPreLogin方法(注意大小写)。这样做的原因是为了避免方法名和Java的关键字冲突，譬如你想使用default这样的方法名，那么你在配置文件仍然可以写上method="default"，然后在Java代码中，你就不能用default做方法名了，因为default是Java的关键字。但是这并不意味着就要把配置文件中method的value给改掉，你只要把方法名换上doDefault就行了。从这里可以看出WebWork考虑入微的一面，当然，我不赞成使用这种方式，毕竟这是以损失效率为代价的。
除了以上方式之外，WebWork还提供了另外一种更为简单的方式调用action中非execute方法：使用actionName!method.action样式的URL。而这种方式并不需要在xwork.xml中增加新的action节点，它将会使用actionName已经定义好的配置。还是以上的例子，如果我们使用Login!preLogin.action这样的URL就会调用Login action中的preLogin方法，也将使用名为Login那个action节点中的配置，同时PreLogin这个节点就可以省略了。这样的方式的好处就是使得xwork.xml配置文件更加简短，不过，两个方法共享一个action配置也给这种方式平添了许多限制，毕竟两个方法返回的结果码不一定都是success和input，即使返回的结果码相同，那么结果码所对应的location呢？完全相同的配置需求确实还是比较少见的。不管怎样，多一个选择总比没有选择要好。
以上只是讲述了WebWork在配置灵活多变的一面，但管中窥豹，WebWork的灵活性已经可见一斑。说完管中窥豹这个成语，另外一个成语在我的脑海中浮现——庖丁解牛。呵呵，真的很期待“以无厚入有间，恢恢乎其于游刃必有余”那种境界。
在这一章中，我了解到了很多之前并不熟悉的配置，而这些配置所带来的影响，我不得不为之赞叹。以action为例，通常我们会根据逻辑来划分action，譬如Login、Register、Search和Logout等等，这些从逻辑语义上独立的部分都应该分别作为一个action，这一点是大家都认可的。在以上这些action的周边仍然会有一些其他附属功能，譬如在Login之前需要做的准备工作——PreLogin；在Search之后需要作进一步搜索的SearchMore。在面对这样的功能时候，你或许会将它们独立出来，作为一个新的action，同时也有可能想着将这些功能放到主逻辑功能当中去。如果你选择了后者，然后兴冲冲地打开IDE想往里面加方法的时候，或许你会犯愁了：方法加了进去，该在哪里调用呢？因为在应用程序运行的时候，WebWork框架只会调用继承的execute方法，那么自己加进去的方法呢？难道真的要在execute中调用？这不是又跟其他功能扯上关系了嘛？不要着急，且听我慢慢说来。
其实，以上说了那么多，只是想为大家勾勒一个应用场景而已。撇开那些复杂的场景不谈，需要解决的问题实际就是：如果让框架调用execute以外的方法。了解WebWork的您应该都十分了解：我们通常所写的action都会extend了ActionSupport类并且需要提供一个override的execute方法，然后在收到请求之后，WebWork框架会将请求分派给不同的action，由action的execute方法来处理这个请求。这就是框架所带来的好处：更加有序地组织代码；同时这也是一个限制。框架都会在限制与功能之间寻找一个平衡点，一个好的框架则会将这对矛盾处理得很好：有一定程度的限制，又不失灵活和强大功能，而WebWork就是这样一个框架。正当你为无法调用execute以外的方法而懊恼的时候，你会惊喜地发现WebWork提供了一种灵活的方式，让你只需修改一下配置文件就可以调用action中execute以外的方法，这样就不需要为一些主逻辑的周边功能而创建新的action类了，让你在设计的时候有更多的选择。要实现框架调用action中execute以外的方法，只需要设置好action节点的method属性即可。如以下例子所示：
<action name="Login" class="com.fantasysoft.Login"> <result name="success">userProfile.jspresult> <result name="input">login.jspresult>action><action name="PreLogin" class="com.fantasysoft.Login" method="preLogin"> <result name="success">login.jspresult> <result name="error">error.jspresult>action>以上例子中名为PreLogin的action节点配置就会调用Login action中的preLogin方法，而不是常见的execute方法了。这里还有一个十分灵活的地方需要注意的，如果preLogin方法找不到的话，WebWork并不会马上抛出Exception，而是进而查找doPreLogin方法(注意大小写)。这样做的原因是为了避免方法名和Java的关键字冲突，譬如你想使用default这样的方法名，那么你在配置文件仍然可以写上method="default"，然后在Java代码中，你就不能用default做方法名了，因为default是Java的关键字。但是这并不意味着就要把配置文件中method的value给改掉，你只要把方法名换上doDefault就行了。从这里可以看出WebWork考虑入微的一面，当然，我不赞成使用这种方式，毕竟这是以损失效率为代价的。
除了以上方式之外，WebWork还提供了另外一种更为简单的方式调用action中非execute方法：使用actionName!method.action样式的URL。而这种方式并不需要在xwork.xml中增加新的action节点，它将会使用actionName已经定义好的配置。还是以上的例子，如果我们使用Login!preLogin.action这样的URL就会调用Login action中的preLogin方法，也将使用名为Login那个action节点中的配置，同时PreLogin这个节点就可以省略了。这样的方式的好处就是使得xwork.xml配置文件更加简短，不过，两个方法共享一个action配置也给这种方式平添了许多限制，毕竟两个方法返回的结果码不一定都是success和input，即使返回的结果码相同，那么结果码所对应的location呢？完全相同的配置需求确实还是比较少见的。不管怎样，多一个选择总比没有选择要好。
以上只是讲述了WebWork在配置灵活多变的一面，但管中窥豹，WebWork的灵活性已经可见一斑。说完管中窥豹这个成语，另外一个成语在我的脑海中浮现——庖丁解牛。呵呵，真的很期待“以无厚入有间，恢恢乎其于游刃必有余”那种境界。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/16629/viewspace-78733/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
关注WebWork（三）
下一篇：
oracle 常用SQL查询
请登录后发表评论
登录
全部评论
