(A5)Tapestry Core:Page Navigation

chinajavawolf

浏览: 117078 次
性别:
来自: 哈尔滨

最近访客更多访客>>

w363042254

hao_chun

feifeng3000

yao_zonghai

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Tapestry

Tapestry 应用服务器浏览器 DAO 数据结构

本人翻译目的是用来学习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内(就是上面讨论的活化上下文)。.
激活服务提拱了粗略的方法去校验页面是否有权使用。

稍后的情形里，验证，通常涉及到用户标识和访问；如果你的页面仅允许特定的用户访问，你就可以用页面的激活事件管理器来负责这个访问的校验。

一个页面的激活事件管理器对应着它的钝化处理器：

void onActivate(long productId)
{
_product = _productDAO.getById(productId);
}
. . .

在此相关的部分是：当页面呈现时，它可能包含更多的动作请求URLs（链接与表单）。在执行其他的操作前,那些链接与表单的动作请求也一样要通过激活页面开始。这形成了一个连续的包含同样活化上下文的请求链。

在某种程度上，这个效果可以通过使用一个持久页面值来完成，但这需要一个激活的session,并且结果是不可被标记的。

激活事件处理器也可以返回一个值，它与动作请求的事件触发器返回的值是一样的。这通常被用于一个访问验证场景。

页面导航模式

动作链接和上下文及页面上下文可以以多种方式组合在一起。

让我们使用一个产品目录页带来一个典型的主/细关系。在这个例子中，ProductListing页面是一个产品的列表，ProductDetails页是显示特定产品的详细页。

多做请求/持久数据

这种模式下，ProductListing页面使用动作事件和一个ProductDetails页面的持久化属性。

ProductListing.html:

<t:loop source="products" value="product">
<a t:type="actionlink" t:id="select" context="product.id">${product.name}a>
t:loop>

ProductListing.java:

@InjectPage
private ProductDetails _details;
Object onActionFromSelect(long productId)
{
_details.setProductId(productId);
return _details;
}

ProductDetails.java:

@Inject
private ProductDAO _dao;
private Product _product;
@Persist
private long _productId;
public void setProductId(long productId) { _productId = productId; }
void onActivate()
{
_product = _dao.getById(_productId);
}

这是一个最小的方法，但对于原型来说已经足够好了。

当用户点击一个链接时，动作请求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:

<t:loop source="products" value="product">
<a t:type="pagelink" page="productdetails" context="product.id">${product.name}a>
t:loop>

ProductListing.java:

不需要代码来支持链接。

ProductDetails.java:

@Inject
private ProductDAO _dao;
private Product _product;
private long _productId;
void onActivate(long productId)
{
_productId = productId;
_product = _dao.getById(_productId);
}

long onPassivate() { return _productId; }

setProductId()方法不再需要。

局限性

随着你应用流程的扩展，你可能会发现找不到一个合理的方式去避免在请求间，在页面活化上下文之外持久化某些数据。比如：如果从ProductDetails页面开始，允许用户导航到相关的一些页面然后返回到ProductDetails页面，这就开始变成必须在页面到页面再到页面间保持传递产品id。

在某些方面，持久化值更有意义。不久，将有一个客户端持久化策略对持久化数据进行编码，如产品id属性,自动的加入到查询参数中（和隐藏的表单属性）。

分享到：

(A6)Tapestry Core:Form Input and Validat ... | (A4)Tapestry Core :Component Parameters

2007-05-09 22:25
浏览 2357
评论(0)
论坛回复 / 浏览 (0 / 3299)
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论