论坛首页 → Java企业应用论坛 →

(A5)Tapestry Core:Page Navigation

浏览 3298 次
锁定老帖子 主题：(A5)Tapestry Core:Page Navigation
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
  • chinajavawolf
  • 等级: 四星会员
  • 性别:
  • 文章: 69
  • 积分: 379
  • 来自: 哈尔滨
   发表时间：2007-05-09  

本文翻译出处 http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html

本人翻译目的是用来学习Tapestry5的,共享出来希望大家批评指正。计划持续翻译。

chinajavawolf

页面导航
实际上，Tapestry应用就是许多相关页面在一起工作。在某种程度来讲，每一个页面就是一个应用。
任何单独的请求都对应一个单独的页面。请求来源于两种情形：
  • 动作请求在特定的页面上对应到特定的组件，在组件内部触发一个事件。
  • 呈现请求对应一个特定页面，将页面的HTML标记流输出到客户端。
动作请求和呈现请求在Tapestry5中是一个新的概念。它在某些方面是基于Portlet规范思想并且区分出这两种类型的请求减轻了许多传统web应用涉及到的浏览器后退按钮或者用户在浏览器里点击刷新按钮。
动作请求
动作请求表现为超链接(ActionLink)或表单提交(Form)的形式。
 
在两种情况下，事件处理方法控制器返回的值发送往给客户端web浏览器的响应。
动作请求的URL包含页面名字、组件的嵌套id和在组件中触发事件的名字（通常是"action"）。此外，一个动作请求可以包含额外的上下文信息，以提供给事件处理器方法。
这些URLs暴露了一些应用的内部结构。随着时间的推移，一个应用程序随着增长和维护，组件的id可能会改变。这就意味着动作请求的URLs不能被收藏。幸运地，用户没有机会去这样做（见下文）：
空值响应
如果一个事件处理器方法没有返回值或返回null值，那么当前页面将会呈现响应。
 
当客户端重定向时，对于当前页的一个页面呈现连接被创建并且发送给客户端。客户端浏览器将自动提交一个新的请求给产生的页面。
用户将会在浏览器看到一个新产生的内容。另外，地址栏里的URL将会是一个呈现请求的URL。呈现请求的URLs简短且包含较少的应用结构信息（比如，他们不包含组件id或事件类型）。呈现请求URLs是用户可以用来收藏的。动作请求URLs是暂时性的，仅当应用处于激活状态时有意义，并不意味着可以被随后的session使用。
字符串响应
当返回一个字符串时，该字符串应该是页面的逻辑名（不是页面的类全名）。另外，页面的名字不区分大小写。
 
此外，呈现请求URL将被构造并重定向到客户端。
页面响应
你可以返回一个页面实例，而非一个页面名字。
页面通过InjectPage标注被注入。
通常，你将会在返回页面前以某种方式配置页面（举例如下）。
 
你也可以返回一个页面内的组件，但这将会产生一个运行时警告。
链接响应
事件处理器方法可以直接返回一个链接实例，这个链接被转换为URL然后重定向URL到客户端。
ComponentResources对象被注入到页面（和组件）中，它的方法可以创建动作action和 页面链接（它们实际上定义在ComponentResourcesCommon中）。
流响应
一个事件处理器也可以返回一个StreamResponse对象，这个对象装入一个流直接发送给客户端浏览器。对于组件想要去产生一个iamge或则PDF提供给浏览器是有用的。
对象响应
事件处理方法返回任何其他对象类型都是错误的。
页面呈现请求
呈现请求在结构和行为上都比动作请求简单。在简单情况下，URL仅仅是页面的逻辑名。
页面拥有一个活化的上下文。这个活化上下文就表现为关于页面状态的持久信息。实际上，这个活化的上下文通常就是一些数据库持久化对象的id.
当一个页面有活化上下文时，上下文的值被附加到URL路径中。
 
并不是所有的页面都有活化上下文。
当呈现请求链接被创建时（PageLink组件有一个上下文参数可以用于此），活化上下文可以被明确的设值。当没有明确的活化上下文被提供时，页面本身会查找它自身的活化上下文。
这种查找体现为事件触发的形势。事件名字是“passivate”（我们马上会看到有一个相对应的“activate”）。方法返回的值被用做上下文。例如：
java 代码
活化上下文可以由一连串的值组成，即方法返回值将是数组或列表。
页面激活
当一个页面呈现请求到来时，页面会在它呈现前被激活。
 
激活服务的两个目的：
  • 激活服务允许页面去重置内部状态数据编码到RUL内(就是上面讨论的活化上下文)。.
  • 激活服务提拱了粗略的方法去校验页面是否有权使用。
稍后的情形里，验证，通常涉及到用户标识和访问；如果你的页面仅允许特定的用户访问，你就可以用页面的激活事件管理器来负责这个访问的校验。
一个页面的激活事件管理器对应着它的钝化处理器： 
 
  1. void onActivate(long productId)   
  2. {   
  3.     _product = _productDAO.getById(productId);   
  4. }   
  5.   
  6. . . .  
在此相关的部分是：当页面呈现时，它可能包含更多的动作请求URLs（链接与表单）。在执行其他的操作前,那些链接与表单的动作请求也一样要通过激活页面开始。这形成了一个连续的包含同样活化上下文的请求链。
在某种程度上，这个效果可以通过使用一个持久页面值来完成，但这需要一个激活的session,并且结果是不可被标记的。
激活事件处理器也可以返回一个值，它与动作请求的事件触发器返回的值是一样的。这通常被用于一个访问验证场景。
页面导航模式
动作链接和上下文及页面上下文可以以多种方式组合在一起。
 
让我们使用一个产品目录页带来一个典型的主/细关系。在这个例子中，ProductListing页面是一个产品的列表，ProductDetails页是显示特定产品的详细页。
多做请求/持久数据
这种模式下，ProductListing页面使用动作事件和一个ProductDetails页面的持久化属性。
ProductListing.html:
 
 
  1. <t:loop source="products" value="product">  
  2.     <a t:type="actionlink" t:id="select" context="product.id">${product.name}a>  
  3.  t:loop>  
ProductListing.java: 
  1. @InjectPage  
  2.  private ProductDetails _details;   
  3.     
  4.  Object onActionFromSelect(long productId)   
  5.  {   
  6.     _details.setProductId(productId);   
  7.        
  8.     return _details;   
  9.  }   
ProductDetails.java:
 
  1. @Inject  
  2. private ProductDAO _dao;   
  3.   
  4. private Product _product;   
  5.   
  6. @Persist  
  7. private long _productId;   
  8.   
  9. public void setProductId(long productId) { _productId = productId; }   
  10.   
  11. void onActivate()   
  12. {   
  13.    _product = _dao.getById(_productId);   
  14. }   
这是一个最小的方法，但对于原型来说已经足够好了。
 
当用户点击一个链接时，动作请求URL将像"http://.../productlisting.select/99"起始，然后最终呈现请求的URL将会像"http://.../productdetails"。注意产品id（"99"）并没有显示在呈现请求的URL中。
它有一些次要的缺点：
  • 它需要一个session（用来保存_productId属性在请求之间）。
  • 如果ProductDetails页面在被访问前设置了一个有效的产品id，就可能失败。
  • URL没有指出产品的标识，如果用户收藏了这个URL，随后回来，他们会触发先前的情况（没有有效的产品id）。
动作请求/持久化数据
我们可以使用钝化和活化上下文来避免使用session并使链接更可收藏，这样就能在不改变ProductListing页面的情况下改进前面的实例。
ProductDetails.java:
 
java 代码
这个改变保证了呈现请求URL将包括产品id,如："http://.../productdetails/99".
这种方法在类型安全的java代码中发生从页面到页面的连接时是有优势的，ProductListing的onActionFromSelect方法。它也有缺点就是点击一个链接服务端需要两次往返过程。
呈现请求一次
这是一个最通用的主/细关系版本。
ProductListing.html:
 
  1. <t:loop source="products" value="product">  
  2.     <a t:type="pagelink" page="productdetails" context="product.id">${product.name}a>  
  3.  t:loop>  
ProductListing.java:
不需要代码来支持链接。
ProductDetails.java:
  1. @Inject  
  2.  private ProductDAO _dao;   
  3.      
  4.  private Product _product;   
  5.     
  6.  private long _productId;   
  7.       
  8.  void onActivate(long productId)   
  9.  {   
  10.     _productId = productId;   
  11.        
  12.     _product = _dao.getById(_productId);   
  13.  }   
 
 long onPassivate() { return _productId; }
setProductId()方法不再需要。
局限性
随着你应用流程的扩展，你可能会发现找不到一个合理的方式去避免在请求间，在页面活化上下文之外持久化某些数据。比如：如果从ProductDetails页面开始，允许用户导航到相关的一些页面然后返回到ProductDetails页面，这就开始变成必须在页面到页面再到页面间保持传递产品id。
在某些方面，持久化值更有意义。不久，将有一个客户端持久化策略对持久化数据进行编码，如产品id属性,自动的加入到查询参数中（和隐藏的表单属性）。
返回顶楼
         
论坛首页 → Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics