实现一个基于 SharePoint 2013 的 Timecard 应用（中）

门户视图

随着 Timecard 列表的增多，如何查找和管理这许多的 Timecard 也就成了问题。尤其对于团队经理而言，他除了自己填写的 Timecard，还要审核团队成员的 Timecard 任务更重。

 

这里我把实际的需求简化成为 2 个主要的视图（但能够提供的效果和实际需求其实是非常接近的）：

1. Time Window 视图
   这个视图列出当前用户在所有可以填写的时间窗口中是否提交了 Timecard，起到提醒的作用。
   
2. Timecard 视图
   这个视图列出在 Timecard 网站中，所有当前用户参与（包括提交和审批 Timecard）的项目/组织中的 Timecard 的审批状态。方便了解自己的 Timecard 填报进展、方便团队经理查找还没有审批的 Timecard。
   

 

技术方案

2个门户视图有很多种技术方案来实现。

• Content Query Web Part 或者 Content Search Web Part。实现第二个视图还勉强可以，注意，只是勉强。实现第一个视图需要 Group Count 功能，直接歇菜。Pass。
• 可视化 Web Part。C# 开发，服务器（场）部署。可以利用服务器端的缓存技术来提高性能。不过，调试是个噩梦，不信你可以搬着指头数数你重启一次 Web Front 需要多少秒。
• Sandbox Web Part。C# 开发，网站部署。具有上面服务器场方案的优点外也避免了它的缺点。不过 SharePoint 2013 叫大家不要用。
• SharePoint Hosted App。JavaScript 开发，服务器（场）发布、网站部署。需要额外配置一个专用的 app 域名和证书。其实这个方案不错，扩展性也很好。但是相比下面的方案，实现显得复杂了点儿。（另外，如果有时间折腾，其实 Provider Hosted App 也可以考虑，这个甚至允许你用 PHP 来写。是那些不喜欢（不愿意喜欢）SharePoint 而又不得不用 SharePoint 的人的不二之选）。顺带提一句，所有 App 方案都有一个巨大初始的优势：调试。直接用 VS 调 JavaScript，那是相当喜闻乐见的。为什么说是“初始”的优势呢？因为一旦基本的 SharePoint 操作你都调得差不多了（熟练掌握）的时候，这个优势就慢慢消失了，那个时候，你的 JavaScript 代码其实已经不容易出现无法在 failure 函数里面捕获的错误了。
• Embedded JavaScript，在网页上面嵌 JavaScript 代码。实现起来最简单，最好维护，对服务器端压力也最小，不刷屏，保护视力。就以上门户视图的需求来看，我选择这个方案。而且，这个方案的代码，搬到 SharePoint Hosted App 也不浪费的。

 

技术实现

JavaScript （SharePoint CSOM）开发，最烦的是其异步回调的机制。所有向服务器发送的操作，都要在回调函数里面收结果，然后你才能继续下一步的业务逻辑。

目前我找到的比较容易减轻这个症状的方案，是用 Deferred。先将调用服务器的操作用 Deferred 包装，然后用 $.when 来调用并捕获其返回结果。这样，至少形式上看上去，后续的业务逻辑操作是紧跟在前面一步的服务器调用后面的，看上去就舒服多了。

也有很多 JavaScript 的函数库提供了这个问题的解决方案，但在试用之后，我都放弃了。简单的问题还是用简单的方案吧。

 

为了说明这个实现方法，我们先看一个空的 Deferred 包装的 SharePoint 调用：

return $.Deferred(function (dtd) {
    var web = context.get_web();
    sp.context.load(web);
    var failure_callback = Function.createCallback(onSharePointFailed, dtd);
    sp.context.executeQueryAsync(
        function () {
            var title = web.get_title();
            dtd.resolve();
        },
        Function.createDelegate(this, failure_callback));
}).promise();

 

上面的例子中，context 是在调用前初始化好了的 SharePoint Context 全局变量，而 onSharePointFailed 则是预先定义的出错回调函数。

通过上面这样的形式，就完成了一个最简单的 Deferred 封装。

 

为了使用上面的封装，我们先要将其放入一个函数中去：

var spGetWeb = function () {
    var web = context.get_web();
    context.load(web);
    var failure_callback = Function.createCallback(sp.Failed, dtd);
    sp.context.executeQueryAsync(
        function () {
            var title = web.get_title();
            dtd.resolve();
        },
        Function.createDelegate(this, failure_callback));
    }).promise();
}

 

好了，下面就可以开始调用了（这只是个例子，真的要调用，还是要做很多准备的，比如初始化 context 等等）：

$.when(spGetWeb())
    .done(function(){
        message.succeed("Web is ready.");
        $.when(spGetList("Time Window"))
            .done(function(){...})
            .fail(function(){...});
    })
    .fail(function(){
        message.error("Can't get the web.");
    }}

 

 

上面的例子中，先调用了 spGetWeb，在成功以后（done），接着又调用了 spGetList。这样，原先像面条一样散落的回调业务逻辑，可以用比较人性化的方式呈现了，我们也好少死几个脑细胞。

 

下面的视频是实现的效果：