WCF Services
and Ajax Calls - Part 3

Introduction

This is the third part of a three part series looking at setting up a WCF service in Sitefinity. In part one I looked at creating the service and the request and response models. The second part dealt with validation. Part three I will go through using jQuery to call our new WCF service.

In this post I won't be talking about any client side validation. It is up to you to decide what validation is required for your particular senerio. We have already implemented our server side security validation which is the important piece in part two and as I mentioned there I keep my two validations separate.

On the client side for a Get request it is straight forward. You can use the standard jQuery $.get function.

If you are Posting then it’s a bit more in depth and requires some explicit properties. (You can probably see why WCF didn't take off compared to the ease of WebApi.)

First, get your data, in my case a contact form. And wrap it into a JavaScript object.

var formData = {
    Name: $('#name').val(),
    Email: $('#email').val(),
    Message: $('#message').val()
};

Next use the jQuery $.ajax function to POST to your web service. Remember our web service starts with a Virtual Path that we set up in Part 1.

var request = $.ajax({
    type: "POST",
    url: "/PdrMyService/Services/ContactForm.svc/SubmitContactForm",
    data: JSON.stringify(formData),
    contentType: "application/json",
    dataType: "json"
});

For the data property we use the JSON.stringify method to properly format our data object into JSON.

We also explicitly set the contentType to 'application/json'. This puts a header in our request to the server that we are sending JSON.
The dataType property is set to 'json'. This tells jQuery that it will be receiving JSON as the response.

If we leave the web service and jQuery to try and figure it out they both get them wrong.

Next we handle the response. Recall from Part 1 and 2 that I tried to ensure that no matter what happened server side a response was returned to the client in a format we expected. One thing we can't handle is any network issues to our service endpoint so we have a handle that in our ajax fail handler. In our success\done handler we need to check our expected response for success and failuer and then its up to you what to do on the client side. In my example I set a status.text element to the message and if its a failure I make it red otherwise I set my input properties to empty strings.

request.done(function (serviceResponse) {
    status.text(serviceResponse.Response.Message);
    if (serviceResponse.Response.Status !== "success") {
        status.css("color", "Red");
    }
    if (serviceResponse.Response.Status === "success") {
        $('#name').val("");
        $('#email').val("");
        $('#message').val("");
    }
                        
});
request.fail(function(data) {
    status.text("There was an error communicating with our web server! " + data);
});

Something extra

I also add a time delay around my requests.

status.text("Thanks, we are processing your comment...");
 
setTimeout(function () {
    // the three snippets above in here
}, 2000);

Why???, well sometimes it’s just too fast and the user never sees my messages. Or they get a glimpse but it passes so fast and they get worried that they missed something important.

I think that from a UX point of view this is bad. My personal belief is that people prefer to have time to read the messages and a delay of 2 sec gives a better experience to the user. (Despite the fear that this will result in a slow page feel.)

So I display an initial message on the button click. In this case setting the status.text message. Then wait at least 2 seconds before making the ajax request.(Feel free to bag me on this one)

Alternatively you could put this in the ajax success\done method. The way I have done it above is 2 seconds plus the request time. Where as if you place it in the success\done then it isn't cumulative time.

WCF services work but they just aren't as simple as the WebApi. Its not hard, its just that you need to be explicit about the formats. Yet the advantage of using them in a Sitefinity project is that you inherit the Sitefinity service code and get some functions built in. And you are setup to inherit future improvements. Unless they decide to go completely down the Service Stack option...

So that’s it. Is this a good idea? Have I lost the plot or missed the boat? Feel free to offer your comments. I am here to learn as much as you are.

Thanks for reading and feel free to comment - Darrin Robertson

If I was really helpful and you would buy me a coffee if you could, yay! You can.

Make a Comment

Name:

Email:

Message:

Enter the code

Sitefinity

Stuff

PDR Group Ltd

WCF Services
and Ajax Calls - Part 3

Introduction

Something extra

Make a Comment

WCF Servicesand Ajax Calls - Part 3

Introduction

Something extra

Make a Comment

WCF Services
and Ajax Calls - Part 3