Implement a timecard application (medium) based on SharePoint 2013)

Portal View

As the timecard list increases, how to find and manage many timecard becomes a problem. Especially for a team manager, in addition to the timecard he entered, he also needs to review the timecard tasks of team members.

 

Here I want to simplify the actual requirements into two main views (but the results are very similar to the actual requirements ):

1. Time Window View
   This view lists whether timecard has been submitted by the current user in all time windows that can be filled in, which serves as a reminder.
   
2. Timecard View
   This view lists the approval status of timecard in the project/organization where all current users participate (including submitting and approving timecard) on the timecard website. You can easily understand the progress of your timecard reporting and help the team manager find the timecard that has not been approved.
   

 

Technical Solution

There are many technical solutions for implementing the two portal views.

• Content Query Web part or content search Web part. You can barely implement the second view. Note that it is barely possible. To implement the first view, you must use the group count function to directly stop the dishes. Pass.
• Visualize Web parts. C # development, server (farm) deployment. The cache technology on the server can be used to improve performance. However, debugging is a nightmare. If you don't believe it, you can stick your finger to count how many seconds it takes to restart Web Front once.
• Sandbox Web part. C # development and website deployment. The advantages of the above server farm solution also avoid its disadvantages. However, Sharepoint 2013 is not recommended.
• SharePoint hosted app. Javascript development, server (field) release, and website deployment. You need to configure a dedicated app domain name and certificate. In fact, this solution is good, and the scalability is also good. However, the implementation is more complex than the following solution. (In addition, if you have time to wait, you can also consider the provider hosted app, which even allows you to write in PHP. It is the best choice for those who do not like SharePoint and have to use Sharepoint ). By the way, all app solutions have a huge initial advantage: debugging. Directly Using vs to call Javascript is quite popular. Why is it an "initial" advantage? This is because the basic SharePoint operations are almost completed (proficient), and the advantage gradually disappears. At that time, your JavaScript code is no longer prone to errors that cannot be captured in the failure function.
• Embedded Javascript, where JavaScript code is embedded on the webpage. It is the easiest to implement, the best maintenance, and the least pressure on the server, without screen painting, to protect your eyesight. Based on the requirements of the preceding portal view, I chose this solution. In addition, the code of this solution is not wasted when it is moved to the SharePoint hosted app.

 

Technical Implementation

JavaScript (SharePoint csom) development, the most annoying is its asynchronous callback mechanism. All the operations sent to the server must receive the results in the callback function before you can proceed to the business logic.

Currently, I have found a solution that can easily alleviate this problem by using deferred. Use deferred to encapsulate the operations on the called server, and then use $. when to call and capture the returned results. In this way, at least formally, the subsequent business logic operations are followed by the server call in the previous step, and it looks much more comfortable.

There are also many JavaScript function libraries that provide solutions to this problem, but after the trial, I gave up. For simple problems, use a simple solution.

 

To illustrate this implementation method, Let's first look at an empty deferred wrapped SharePoint call:

   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();

 

In the above example, context is the SharePoint context global variable initialized before the call, while ondomainpointfailed is a pre-defined error callback function.

In the above form, a simple deferred encapsulation is completed.

 

To use the above encapsulation, we need to put it into a function first:

   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: }

 

Okay, now we can start calling (this is just an example. We need to make a lot of preparations, such as initializing the 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:     }}

 

 

In the above example, spgetweb is called first. After the successful call (done), spgetlist is called again. In this way, the callback business logic that was originally scattered like a noodle can be presented in a more humane way, so we can die a few brain cells.

 

The following video shows the effect: