意外～IBM已经开始关注Tapestry

晕，刚发现developerworks中居然有Tapestry文章，而且作者是Brett McLaughlin：http://www-128.ibm.com/developerworks/java/library/j-tapestry1/

IBM关注的东西，似乎是有选择性的，我也不太清楚IBM的意图。搜索了一下，好像没有webwork(我并非有意挑起口水战，只是一时好奇，在IBM搜索了一下他们所关注的内容，也可能是我不太会使用他们的搜索器)。

TAPESTRY值得关注

不是说Struts webwork tapestry他们合了吗？叫Struts Ti
合了还有在从新另立门户的必要吗？

不会有太多口水，webwork/struts 和tapestry还有有很大不同的。

各有优势吧。我就专拣不方便的地方说说，理解有限请随意拍砖：）

webwork 2.1.7
1.jsp作为模板时UI 标签，形成一堆多余的table来包装着表单控件。不用UI标签，就利用不了框架自生成的js输入验证；
2.CRUD in single action虽然在webwork in action中作为最佳实践，但是按例子配置，Save和Delete等method还会受到Create，Update等method的输入验证的影响，需要分别配置interceptor stack。
3.一堆辅助的框架需要了解，比如组件式的页面布局最好了解sitemesh？不如tapestry的一揽子解决方案(Border组件就是天然的布局利器)。
4.模板众多，选择多有时未必是好事。别人用freemarker写的例子，我就看不懂，因为只看得懂veloctiy和jsp。还有一堆特殊符号需要学习。
5.其他还没了解到的...

tapestry 4
1.一个庞大的BasePage，暴露了太多方法，且方法名本身还容易混淆（比如pageBeginRender，接口方法beginPageRender等等）得非常了解方法调用的流程，才知道把数据库调用放在合适的地方。webwork的这接口那接口和interceptor组合就有优势了。

2.自成一体的另一种说法就是太封闭。不容易和其他web框架甚至简单的servlet/jsp集成。

3.学习曲线高。

4.其他还没了解的...

可以通过  className-name!create-validation.xml,
className-name!update-validation.xml
这样来做.还有问题,比如可以定义需要的workflow interceptor等.

原来可以这样，又学了一招，

1，实际上，这反而是Tapestry官方推举的一个优势，就是很多底层代码，Tapestry已经帮你完成，不需要你再关注那些繁琐重复的底层代码，你不认为是一种解脱吗？
2，关于这一点，我认可。实际上，这也是一个颇为争论的观点。就是既然你的项目中已经有Tapestry，Tapestry可以完成任何JSP的功能，那么需要还需要使用JSP吗？
3，这个方面，我一直在努力。现在在javaeye的wiki中，你已经可以查找到一些文档。当然，对Tapestry讲解并非一两篇文章就可以解决，我也需要更多时间来完成文档。牛顿认为他是站在巨人的肩膀上，我并非巨人，但是我所做的努力，必然会降低所谓的学习曲线。
4，呵呵，你了解多一些我们再讨论。：）

要么就让我知道得更多，要么就不要告诉我一点细节。继承就是告诉我一些东西但是我实际上得花较多的精力才明白细节的东西。

把数据库调用放在basepage方法里面最合适的地方，还得搞清楚cycle.isRewound() isRewinding()这些细节点，你才不会让关键的代码重复执行两遍。估计得另开一个话题了，暂且打住。

我知道tapestry的todo list 里面有一个pojo式的page 和component，我非常期待！




随便举个例子来说，比如render了某个网上支付的页面，该页面的action是一个外部的URL，这个时候就需要jsp等view了。

当然我也部分解决了这个问题，比如做一个velocity page

public abstract class AbstractVelocityPage extends MyBasePage{

  public abstract int getTemplateType();;

  public abstract String getTemplateSource();;

  public abstract Context getVelocityContext();;

  private void renderVelocityTemplate(IMarkupWriter writer); {
    /**@todo 根据Engine的指定的character encode来设定*/
    TemplateWrapper tw = new TemplateWrapper(getTemplateType();,
                                             getTemplateSource();,
                                             VelocityUtil.createEngine();,
                                             "GBK");;
    writer.printRaw(tw.render(getVelocityContext();););;
  }

  /**
   * Renders the top level components contained by the receiver.
   * @since 2.0.3
   */
  final protected void renderComponent(IMarkupWriter writer,
                                       IRequestCycle cycle); {
    renderVelocityTemplate(writer);;
  }

  /**
   * Loads the template for the component, then invokes
   * {@link AbstractComponent#finishLoad(IRequestCycle, IPageLoader, IComponentSpecification);}.
   * Subclasses must invoke this method first, before adding any additional behavior, though its
   * usually simpler to override {@link #finishLoad();}instead.
   */
  public void finishLoad(IRequestCycle cycle, IPageLoader loader,
                         IComponentSpecification specification); {
    //不需要载入模板了，采用velocity的模板
    //readTemplate(cycle, loader);;
    //super.finishLoad(cycle, loader, specification);;
  }
}

再说一个tapestry不好的：
n)某些太heavy的组件，比如table/tree，得理解一堆model和一堆renderer。我觉得应当选择有代表性的js实现的组件，来包装一下。js可以用在任何web框架中，这样即使脱离了tapestry，也很容易共用代码。


说一万个不好，其实就是期待她更好一些，我期盼tapestry的功能能加上：
1.pages and components  are pojos,上面提到了；
2.支持skin，比如Template_zh_CN.someTheme；
3.static page generate policy(in todo list)；
4.更完善的ajax(also in roadmap)；
5.more...