SiteMap, URL Rewriting, and Dispatching

liftweb作者David关于SiteMap,URL Rewriting, URL Dispatching的讲解

Folks,

lift services HTTP requests in a "render pipeline".

lift is implemented as a Filter (thanks to the excellent suggestion from
Viktor).

When a request comes in, any functions defined in LiftRules.early (see
LiftRules.appendEarly) as executed. This can be used to set Tomcat to UTF-8(jetty也可以)
for parameter parsing (although this is dangerous if lift is one of many
Filters and the other Filters expect different behavior).

When a request comes in, the request re-writing is repeatedly applied to the
request until there are no more matches in the request re-writer partial
function.

The re-written request is then used to create a RequestState instance.

Next, the filter tests the request against LiftRules.isLiftRequest_? to see
if there's a specific rule about the request being handled by lift.

If the request should be handled by lift, the request is passed to an
instance of LiftServlet.

The request is matched against LiftRules.statelessDispatchTable and serviced
if there's a match (this is useful for REST requests that are truly
stateless and there's no desire to create a new Servlet Session for each
request.)

All of the subsequent handlers are done inside the "S" context (thus, they
have access to session state):

If the request matches LiftRules.dispatchTable, then the request is handled
by dispatchTable.

If the request is a Comet request, it's handled by the Comet handler.

If the request is an Ajax request, it's handled by the Ajax handler.

Otherwise, the request is handed off the the LiftSession for further
processing.

In the LiftSession, the request is tested against session specific
dispatchers (see S.highlevelSessionDispatcher) and dispatched if there's a
match.

Next, the request is tested against SiteMap (if SiteMap is defined). If the
page is guarded by SiteMap and the guard fails, then the appropriate
response is sent to the browser.

Otherwise, the template for the incoming request is located.

First, the LiftRules.templateTable is consulted (this is a method which
combines session specific template lookup with LiftRules-based template
lookup.) If the template is located, it's returned.

Otherwise, the parts of the path that start with '.', '_' or contain
'-hidden' are removed and the resource is looked up in
LiftSession.findAnyTemplate.

findAnyTemplate looks for a given named resource (given suffixes and
locales). If the resource cannot be located, a class and method are
searched for in the "valid packages".view packages.

Once the template is located, it is processed by processSurroundAndInclude.

Questions?

Thanks,

David
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值