In the previous entry: "Editing Tasks" we walked through the process of allowing our users to update their own tasks. In this entry we will walk through a similar process, but this time allowing our users to delete tasks if they choose. Keep in mind that users can only edit and delete tasks which are their own.
Creating the DeleteTask Stored Procedure
You probably guessed it already… and if you did that’s awesome… we will first create our stored procedure to delete tasks. The DELETE command is another command that you want to use with caution because depending on how you code it you can potentially delete a lot of data that you don’t want to delete. Delete statements also make use of the WHERE clause. So anytime you find yourself coding out a DELETE script be sure to proceed with caution.
Open SQL server, expand the ModDev2 database (or whatever you named yours), and right click and open a new query window. In order to create the delete task procedure paste in the following code:
CREATE PROCEDURE CBP_DeleteTask
@TaskId int
AS
DELETE FROM CBP_Tasks
WHERE TaskID = @TaskId
GO
In the delete task procedure script above we, again, create the procedure name with a prefix then pass in a parameter of @TaskId because we only want to delete the task when the TaskId being passed in as the parameter equals the TaskId in the task table. This ensures that we will just delete one task.
Updating the SQL DataProvider File
And you probably guessed the next step too… now that we have our stored procedure we need to update our SQLDataProvider file which has some DNN specific syntax as shown below:
And here’s the code snippet:
IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = object_id(N'{databaseOwner}[{objectQualifier}CBP_DeleteTask]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE {databaseOwner}{objectQualifier}CBP_DeleteTask
GO
CREATE PROCEDURE {databaseOwner}{objectQualifier}CBP_DeleteTask
@TaskId int
AS
DELETE FROM {databaseOwner}[{objectQualifier}CBP_Tasks]
WHERE TaskID = @TaskId
GO
Creating the DeleteTask TaskController Class
With our stored procedure correctly functioning we now need to create our DeleteTask Controller class. If you are picking up on our pattern of updating the stored procedure, then controller class, then web service, then the View control then you are learning and that’s good! Of course there’s no written rule that this is the order in which you have to create these. You can obviously create your files in whatever order makes most sense to you. As I think in a linear perspective this method best helps me keep things in line in my mind.
In Visual Studio open up the TaskController.cs file. Just below the “UpdateTask” method add the DeleteTask controller as shown below:
And if you want to copy & paste:
public void DeleteTask(int taskId)
{
DataProvider.Instance().ExecuteNonQuery("CBP_DeleteTask", taskId);
}
In this method again we are using the “public void” because no data set is being returned. We pass in the parameter of taskId. Then we create an instance of the DataProvider and call the “ExecuteNonQuery” SQL method and to that method we pass in the string of the stored procedure we want to execute, which in this case is our “CBP_DeleteTask” method that we just created. We also pass in the taskId because the stored procedure is expecting this parameter.
Creating the DeleteTask Web Service
With our TaskController now having the delete method in place we are ready to proceed and create our Web service. In Visual Studio open the WebServices.cs file and just below the UpdateTask method add in the following code:
And if you want to copy and paste the code:
public class TaskToDeleteDTO
{
public int TTD_TaskID { get; set; }
}
[DnnModuleAuthorize(AccessLevel = SecurityAccessLevel.View)]
[ValidateAntiForgeryToken]
[HttpPost]
public HttpResponseMessage DeleteTask(TaskToDeleteDTO DTO)
{
try
{
var task = new Task()
{
TaskId = DTO.TTD_TaskID
};
TaskController tc = new TaskController();
tc.DeleteTask(task.TaskId);
return Request.CreateResponse(HttpStatusCode.OK);
}
catch (Exception exc)
{
return Request.CreateErrorResponse(HttpStatusCode.InternalServerError, exc);
}
}
Here again we define a class for our data-transfer-object. This “TaskToDeleteDTO” will be an object that holds the taskId for the task that we want to delete. This data for this data-transfer-object will again come from our View.ascx. With the service method code again we include the security access level attribute, the ValidateAntiForgery token, and the request type declaration… this delete will be a POST request as well. Then we create the HttpResponseMessage “DeleteTask” and into it we pass in the “TaskToDeleteDTO” object named DTO. Within the try/catch block we create a new task object and set the TaskID property. Next we create a new TaskController named “tc” and on that TaskController we call the “DeleteTask” controller method that we just created. Finally we return the HttpStatusCode of “ok” to complete our service code. In the catch block we log any exceptions in case that something does go wrong with our service.
Updating the View.ascx
With all of our other components correctly configured we’re now ready to update the View.ascx file. This update will be fairly simple. Whenever a user clicks the “Edit” link we are currently showing them a cancel and a save button. We are going to update this and also add in a “delete” option.
In the section that has the comments //Append cancel and save options… add in this new line
$('.TaskList').find('' + EditListItemDiv + '').append('<div class="Delete" id="' + EditClickedID +'">Delete</div>');
Now your code block should look like this:
Here again we are using jQuery to find the specific DIV whose edit button was clicked and then we are appending cancel, save, and now delete options to it.
Cancel, Save, & Now Delete
Thus far we’ve created script blocks for when the user clicks both cancel and save after they’ve edited their task. Now we need to add in a block for when the user clicks “Delete”. Just below the save button code block add in the following snippet:
$('.Delete').click(function() {
var DeleteClickedID = $(this).attr('id');
$.dnnConfirm({
text: 'You sure you want to delete',
yesText: 'Yep,delete',
noText: 'Cancel',
title: 'Delete Confirmation',
callbackTrue: function() {
deleteTask(DeleteClickedID);
}
});
function deleteTask(DeleteClickedID) {
var taskId = DeleteClickedID;
var taskToDelete = {
TTD_TaskID: taskId,
};
var sf = $.ServicesFramework(<%:ModuleContext.ModuleId%>);
$.ajax({
url: '/DesktopModules/MyFirstModule/API/ModuleTask/DeleteTask',
type: "POST",
contentType: "application/json",
beforeSend: sf.setModuleHeaders,
data: JSON.stringify(taskToDelete),
success: function(data) {
loadTasks();
}
});
}
});
Looking at this code we see that we are again using jQuery to find the unique ID of the delete button that got clicked. This way we’ll know which task should be deleted. We set this value to a variable called “DeleteClickedID”.
Guarding Against Accidental Deletion
Then you see something new… you see the $.dnnConfirm code block. If you think about it… we’re going to have our delete button very close to our save & cancel button. This is bad user interface design on my part... feel free to update yours as needed ;-) Since this may not be the best user interface a user may try to click save and accidentally click delete… and that wouldn’t be good... so we should probably update the UI, but we can take some steps to guard against accidental deletion and that’s exactly what that $.dnnConfirm is.
Since we aim to guard against accidental deletion we can prompt the user to confirm that they do in fact want to delete the item they just clicked. Looking at the $.dnnConfirm text you see where we can define a few items in this block. We can tell the pop-up what text we want to present to the user, the “yes” action text, the “no” action text, the pop-up title, and finally the callbackTrue actions. In our code example you see where the callbackTrue option has a function defined and that function is where we call the deleteTask function and pass in the taskId of the item to be deleted. So we added one step in the deletion process, but it acts as a safeguard to our users.
Beneath that we’re back to our same way of calling the service framework, but this time we just reference and updated url… the DeleteTask route of our service. Then once we delete the task, again we call our faithful loadTasks() function.
The below video walks through the concepts covered in this blog entry
Summary
We have indeed come a long way and I hope that you have learned some things, found this helpful, and been able to get your tasks module functioning correctly. Though we aren’t done just yet… we’ve got 1 or 2 more things we need to discuss and illustrate. We’re going to create a setting for our module. I hope to see you in the next blog entry!
Go to the Next Blog Entry: Giving Our Module a Setting