门户视图
随着 Timecard 列表的增多，如何查找和管理这许多的 Timecard 也就成了问题。尤其对于团队经理而言，他除了自己填写的 Timecard，还要审核团队成员的 Timecard 任务更重。
这里我把实际的需求简化成为 2 个主要的视图（但能够提供的效果和实际需求其实是非常接近的）：
- Time Window 视图
这个视图列出当前用户在所有可以填写的时间窗口中是否提交了 Timecard，起到提醒的作用。
- 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 调用：
1: return $.Deferred(function (dtd) {
2: var web = context.get_web();
3: sp.context.load(web);
4: var failure_callback = Function.createCallback(onSharePointFailed, dtd);
5: sp.context.executeQueryAsync(
6: function () {
7: var title = web.get_title();
8: dtd.resolve();
9: },
10: Function.createDelegate(this, failure_callback));
11: }).promise();
上面的例子中，context 是在调用前初始化好了的 SharePoint Context 全局变量，而 onSharePointFailed 则是预先定义的出错回调函数。
通过上面这样的形式，就完成了一个最简单的 Deferred 封装。
为了使用上面的封装，我们先要将其放入一个函数中去：
1: var spGetWeb = function () {
2: var web = context.get_web();
3: context.load(web);
4: var failure_callback = Function.createCallback(sp.Failed, dtd);
5: sp.context.executeQueryAsync(
6: function () {
7: var title = web.get_title();
8: dtd.resolve();
9: },
10: Function.createDelegate(this, failure_callback));
11: }).promise();
12: }
好了，下面就可以开始调用了（这只是个例子，真的要调用，还是要做很多准备的，比如初始化 context 等等）：
1: $.when(spGetWeb())
2: .done(function(){
3: message.succeed("Web is ready.");
4: $.when(spGetList("Time Window"))
5: .done(function(){...})
6: .fail(function(){...});
7: })
8: .fail(function(){
9: message.error("Can‘t get the web.");
10: }}
上面的例子中，先调用了 spGetWeb，在成功以后（done），接着又调用了 spGetList。这样，原先像面条一样散落的回调业务逻辑，可以用比较人性化的方式呈现了，我们也好少死几个脑细胞。
下面的视频是实现的效果：
实现一个基于 SharePoint 2013 的 Timecard 应用（中）,布布扣,bubuko.com