Tapestry 5 原则

原则1：静态结构，动态行为

    “动态行为”的概念对于构建web应用时很明显，不同的用户或情况应该展现不同的东西。但是对于Tapestry，“静态结构”意味着什么？静态结构就是用Tapestry构建一个页面，这个页面包含你定义的所有组件。在任何情况下，渲染或事件处理的页面都能动态的创建组件并放入到组件树里。

    乍一看，这似乎十分有限...其他的框架允许在运行时刻创建新的元素，它也是桌面应用（像Swing）的一个共同特点。静态结构并不像你想的那么有限。你有很多种选择从静态结构中获取动态行为；从简单的条件和循环组件到更高级的Tapestry的BeanEditor或网格组件，Tapestry使你可以自由的控制何时展现或展现什么。

    为什么Tapestry选择静态结构作为一个核心原则？完全是为了灵活性和可扩展性。 

灵活性：

    Tapestry被设计为一个灵活的工作环境；“少代码，多输出”。当你第一次载入你的POJO页面和组件时，你只编写了少量的代码。它也共享页面和组件类的实例（通过多线程和多请求）。有了动态的可逆性的结构将意味着每个请求有自己的实例，并且进一步，在请求的时候整个结构将被序列化，以备存储供后续的请求。   

可扩展性：

    当构建一个大规模系统的时候，考虑每个发布服务上的资源如何利用以及信息如何在服务之间共享显得非常重要。静态结构意味着不需要将页面实例存储到HttpSession中，并且简单的浏览用户不需要额外的系统资源。HttpSession精益使用的关键是Tapestry的高可扩展性，尤其是在集群配置中。另外，连接一个页面实例到一个特定的客户端比拥有一个共享的页面实例需要更多的服务端资源。    

原则2：自适应API

    自适应API是Tapestry5一个关键特征。

    在传统的java框架中，包括Tapestry4，用户的代码应该遵从框架的要求。创建继承框架提供的基类的类，或实现框架提供的接口。在不进行框架版本升级的情况下，这工作的很好。随着新的特性的升级，你会经常考虑版本的向后兼容性。现有的编码会随着接口和基类的改变而改变。

    在Tapestry5中，框架适应你的代码。你能控制方法的名字、参数及返回值。这由注解驱动，告诉Tapestry在什么情况下你的方法被调用。

例子，一个登录表单，方法在表单提交的时候被调用：

public class Login

{

  @Persist

  @Property

  private String userId;

  @Property

  private String password;

  @Component

  private Form. form;

  @Inject

  private LoginAuthenticator authenticator;

  void onValidateFromForm()

  {

    if (! authenticator.isValidLogin(userId, password))

    {

      form.recordError("Invalid user name or password.");

    }

  }

  Object onSuccessFromForm()

  {

    return PostLogin.class;

  }

}

这个简短的代码展示了一些关于Tapestry的操作。应用的页面和服务通过注解@Inject被注入。onValidateFromForm() and onSuccessFromForm()的名字通知了Tapestry，每个方法何时被调用。约定的名字标识了方法被捕捉的事件，（“validate” 和 “success”）和触发事件的组件ID（“form”组件）。

    执行字段校验的时候“validate”事件被触发，并且只有在检验没有错误的情况下“success”事件被触发。onSuccessFromForm()方法的返回值指向了Tapestry下一步做什么：跳转到应用的另一个页面（这里用类标识页面，还有其他一些选项）。当有异常发生，这个页面将重新展现给用户。

    这也是从Tapestry4开始一个独特的改变。在Tapestry早期的版本，Form组件的监听器参数通过名字和方法的调用绑定。进一步，监听方法必须是public的。这个新的途径不止支持多监听器，而且在java类里提高了表现层（在页面的HTML模板里）与逻辑层的分离。

    在许多情况下，事件的额外信息是可以得到的，并能通过添加额外参数的方法传入到方法中。另外，Tapestry 在不管提供的什么命令下将适应你的参数。

    Tapestry也节省非必要的努力：注解@Property标识一个字段可读和写，Tapestry将自动添加访问方法。（get 和 set）。

    最后，Tapestry 5明确将动作（需要改变的东西）和渲染（请求的渲染页面）分成两个独立的请求。执行一个动作，例如点击一个链接或者提交一个表单，结果在客户端重定向了一个新的页面。这经常被叫做“请求后重定向”。这种做法保证了URLs在浏览器中是可预订的...但是也要求在请求的时候存储更多的信息到session中。（用@Persist注解）。

原则3：区分公共（Public）与内部（Internal）APIs

    在Tapestry4和之前的版本都有一个问题就是在私有（private），内部APIs（internal APIs）和公有（public），外部APIs（external APIs）之间缺少一个明确的划分。事实上，你的代码继承基对象，但是基对象的许多方法是“off limits”（禁止入内）的，进一步混淆了问题。这在”Tapestry 陡峭的学习曲线中“作为一个关键的因素被指出。

    用干净的Tapestry5，我们要严格区分内部和外部。

    首先，在the org.apache.tapestry5.internal 包里的任何东西都是内部的。它是Tapestry的部分实现。它是窗帘后面的男人（直译）。你不应该直接使用这些代码。这是一个坏主意，因为内部代码会改变而不去关心

从一个版本到下一个版本的兼容性。

    如果你曾发现你不得不利用内部APIs，请发邮件给开发者，这使我们知道哪个服务应该暴露为public。

原则4：确保向后兼容性

    老版本的Tapestry，发布的每个版本都受到向后兼容性问题的困扰。Tapestry5不想试图向后兼容Tapestry4.然而，它之前做了向后兼容的基础工作。

    Tapestry5的API几乎完全基于命名规范和注解。你的组件只是普通的java类；给字段加注解来允许Tapestry去维持他们的状态或允许Tapestry注入资源，给方法命名（或加注解）告诉Tapestry在什么情况下，方法应该被调用。

    Tapestry 将适应你的类。通过方法参数调用你的方法。而不是强硬的去实现接口，Tapestry通过注解的提示和方法的命名规范简单的适应你的类。

    正因为如此，Tapestry内部的改变在很大程度上不会影响你写的应用代码。这将解决向后兼容性的问题，保证你升级Tapestry未来版本而不会破坏你现有的应用。

    这在Tapestry5.1和Tapestry5.2已经有了明显的体现，尽管加入了许多新特性以及改进，但是却100%向后兼容Tapestry5.0，只要你不用内部APIs。

原文地址：http://tapestry.apache.org/principles.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/796158/viewspace-697824/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/796158/viewspace-697824/