在学习Tapestry之前，先发发牢骚

      我学习TapeStry完全不是我本意，我是觉得这是个不成熟的框架，自己玩玩还好，要是真的应用在项目中风险就有些大了，而且这个框架的学习资料非常有限，各个版本之间的改动非常大，比如现在我们用T5，现在能找到少量的T5的资料，随后T6出来了，T5就完全没人去研究他了，毕竟没人在自己的项目中去用，那些追求新技术的人，也不会停留在T5上，而且我很怀疑这些版本之间能否兼容,因为5.05和5.06之间还出现了文件所在目录不一样的情况。而且页面文件使用的是Tapestry Markup Language，有些HTML的标签在这里使用都会出现问题。但是很不幸的是，我们决定使用这个框架。

        有人说Tapestry 是很有效率的东西，因为它的可重用组件，但是我以我的理解可重用组件这东西，也就是struts2中的标签一样。自己开发也是没有问题的，而且还更灵活。然而使用了Tapestry 以后的维护成本和用人成本将会十分的高，毕竟现在SSH框架是主流，包括JSF等。用的人，懂的人很多，但是要说Tapestry，我象10个程序员中，能找到2个懂的就很不错了，我一直反对去追求不稳定没有经过考验的新技术，以后在开发过程中，招一个人，难道让他丢弃他原有的框架知识和开发习惯，去重新接受一个新的学习曲线很陡峭的框架，去接受另外一种和jsp，struts完全不同的开发习惯？要知道，我们做的可是产品，不是一个做完就OK的项目，以后的版本会在这个版本之上进行，也就意味着所有参与这个项目开发的人都得丢弃原来SSH+jsp的开发习惯，重新选择T。还有人说对于一个不懂JSP的人来说用Tapestry的成本会比struts小的多，唉~~我在想，有几个javaee开发人员不懂jsp的？

         使用一个新的框架个技术，无非是要看它的稳定程度，有没有很成熟的解决方案还有开发成本，包括用人成本，时间成本，学习成本，以及以后的维护成本。Tapestry的代码可读性不强，使用很多的命名规则，或者是元注释，对于不了解的人来说根本就不明白，你无法看到他的底层是怎么执行这个流程的(自己理解：很多东西都是不可控制的，也就是缺乏灵活性，这是现在很多看似用起来非常简单，封装的很好的框架的通病)。任何一个新的技术出来，起初都会有很多人去赞美它的强大，原因是没有人去在项目中真正的使用，他们看到的都是这个技术所带来的新的东西，好的东西，而那些缺点只有在真正的应用中才能暴露出来。看看这个历史(来自javaeye)：

1. 1999~2001之间EJB被各大厂商热炒 (IBM, Bea, Oracle, etc...)

2. 广告铺天盖地, Transaction, Security, Spec, Architecture, Remote procedure calls, Code reuse, Assembly等等buzz word犹如苍蝇成天在你耳边绕

3. 大型项目设计，企业系统构建，言必称采用先进的EJB技术云云

4. 各个银行，证券，保险，大型企业项目都被挂上成功的EJB技术光环

但是后续的发展事实呢：

1. EJB规范1.0及其难用, 厂商们开始推出EJB2，继续不遗余力地忽悠

2. 大规模的批评和抱怨：性能低下，编程效率低，平台成本高

3. Hibernate出现，Spring出现, J2EE development without EJB出现

4. Hibernate/Spring成为Java开发的事实标准

   现在呢？EJB3摆着那里，还听到有谁说它如何如何了得了？

    最后我预测这次采用Tapestry的结果：最好的是能做出来，但是做的一塌糊涂，灵活性不高。原因很简单，1、大家都不会，还有一部分人以前连Tapestry是什么都没听说过；2、建议使用Tapestry的人也不精通。      还有一种结果是直接宣告失败，咱们做了无数无用功，原因是：遇到问题没法解决，网上资料稀缺，如果遇到一个难题就看源码，那是非常痛苦的。

   最后说下tomcat推荐的用maven开发tapestry的J2EE目录，这玩意以后能成为标准吗？