If you're developing rich web clients using Asp.net MVC on the back-end, you've probably come across this functionality that can be described with these conditions:
- client side data (may be a form),
- ajax posting of this data (form),
- controller action has strong type parameters,
- controller action processes data and returns anything but a full view (since it was an Ajax call)
Seems fairly straight forward, right? Well not so fast my fellow developer friend...
The old fashioned way
Validation in Asp.net MVC is really simple and very transparent. If you had to think about it all the time when developing Asp.net Web forms applications, you don't have to do that with MVC anymore. Whenever your controller action takes strong type parameters and you define validation rules on the type itself, you can easily just lay back and watch the magic happen in front of your eyes.
When you don't use Ajax (how old fashioned of you), your form will be posted back the usual way by means of browser reloading the whole page. Because browser reloads the whole page there will be some flickering since it will clear the window at a certain point to render the new response. So your application will have a master view (in terms of master/detail process), where the user could click some Add new link or button that will redirect them to the new entity view (the details view). This view presents a form where they enter relevant data and a button to submit it to server. Your controller action could look very similar to this:
1: [HttpPost]
2: public ActionResult Add(Person instance)
3: {
4: if (!this.ModelState.IsValid)
5: {
6: // return the same view with validation errors
7: return View(instance);
8: }
9:
10: // save the new person instance and go back to master view
11: Person result = this.Service.Add(instance);
12: return RedirectToAction("Index");
13: }
The contemporary way
But since we're savvy web developers, we rather use asynchronous processing these days. Instead of asking the browser to post back data and reload the whole page, we rather issue an Ajax call. This way we avoid page flickering and even the nasty long page scroll position stays the same. Ajax FTW! All today's desktop browsers support this functionality as well. Great way of doing it then.
The whole client process probably changed according to our advanced functionality. We'd still have the master view with the list of all entities, but clicking on the Add new link will most probably present a modal dialog box with the details form instead of redirecting the user to a whole new page. In terms of usability and interface comprehension, this is a much better experience. Something similar is frequently used in Sharepoint 2010 these days. The process would work like this:
- User clicks Add new link on the master view.
- Your javascript dims the master view and displays a dialog box with the new entity form (details view).
- User enters relevant data and clicks the Save link.
- Your javascript issues an Ajax call that posts back data.
- When everything goes according to the plan, server responds either with a
PartialViewResultthat holds visual representation of the newly created entity that can be appended to master page entity list, orJsonResultdata that can be consumed for the same purpose (but you'll have to manually transform JSON to visual HTML representation). - Your javascript closes the dialog box.
- Master view is in full display again and your javascript adds the newly created entity to it's list (while also providing some highlight animation).
1: [HttpPost]
2: public ActionResult Add(Person instance)
3: {
4: if (!this.ModelState.IsValid)
5: {
6: // we'll see this in a bit
7: }
8:
9: // save the new person instance and go back to master view
10: Person result = this.Service.Add(instance);
11: return PartialView("Person", result); // or Json(result)
12: }
When the going gets tough...
So what do we do, when user enters incorrect data into the form that's not valid? You can't just return some other partial view, because javascript expects something else. You could of course put additional functionality on the client side that would detect different HTML being returned, but that's very prone to errors. Think of changing the partial view. Any of the two. DRY again. The best thing would actually be to return a 400 HTTP response and provide the right result in it. Why is this better?
- Because it will keep working even when you completely redesign your views.
- Because it's going to be much easier to distinguish between a successful results and an erroneous one on the client.
1: $.ajax({
2: url: "Person/Add",
3: type: "POST",
4: data: $(this).serializeArray(), // provided this code executes in form.onsubmit event
5: success: function(data, status, xhr) {
6: // YAY! Process data
7: },
8: error: function(xhr, status, err) {
9: if (xhr.status == 400)
10: {
11: // this is our erroneous result
12: }
13: else
14: {
15: // some other server error must have happened (most probably HTTP 5xx)
16: }
17: }
18: });
...the tough get going
To make things reusable on the server side you have two possible (and most obvious) ways of doing it:
- Provide additional controller extension methods like
PartialViewError,JsonError, etc. that will work very similar to their normal counterparts except they'll also set the response status code to 400 (don't forget to check whether this is an Ajax call, because if it's not, don't set status code). - Provide a custom exception and an exception action filter that handles it.
Let's first look at the code of my custom exception. It's called ModelStateException because I throw it on invalid model state and it has a constructor that takes model state and gets the errors automatically from it. This is the code of the exception:
1: /// <summary>
2: /// This exception that is thrown when there are model state errors.
3: /// </summary>
4: [Serializable]
5: public class ModelStateException : Exception
6: {
7: /// <summary>
8: /// Gets the model errors.
9: /// </summary>
10: public Dictionary<string, string> Errors { get; private set; }
11:
12: /// <summary>
13: /// Gets a message that describes the current exception and is related to the first model state error.
14: /// </summary>
15: /// <value></value>
16: public override string Message
17: {
18: get
19: {
20: if (this.Errors.Count > 0)
21: {
22: return this.Errors.First().Value;
23: }
24: return null;
25: }
26: }
27:
28: /// <summary>
29: /// Initializes a new instance of the <see cref="ModelStateException"/> class.
30: /// </summary>
31: public ModelStateException() : base()
32: {
33: this.Errors = new Dictionary<string, string>();
34: }
35:
36: /// <summary>
37: /// Initializes a new instance of the <see cref="ModelStateException"/> class.
38: /// </summary>
39: /// <param name="modelState">State of the model.</param>
40: public ModelStateException(ModelStateDictionary modelState)
41: : this()
42: {
43: if (modelState == null)
44: {
45: throw new ArgumentNullException("modelState");
46: }
47:
48: //this.ModelState = modelState;
49: if (!modelState.IsValid)
50: {
51: StringBuilder errors;
52: foreach (KeyValuePair<string, ModelState> state in modelState)
53: {
54: if (state.Value.Errors.Count > 0)
55: {
56: errors = new StringBuilder();
57: foreach (ModelError err in state.Value.Errors)
58: {
59: errors.AppendLine(err.ErrorMessage);
60: }
61: this.Errors.Add(state.Key, errors.ToString());
62: }
63: }
64: }
65: }
66:
67: /// <summary>
68: /// Initializes a new instance of the <see cref="ModelStateException"/> class.
69: /// </summary>
70: /// <param name="info">The <see cref="T:System.Runtime.Serialization.SerializationInfo"/> that holds the serialized object data about the exception being thrown.</param>
71: /// <param name="context">The <see cref="T:System.Runtime.Serialization.StreamingContext"/> that contains contextual information about the source or destination.</param>
72: /// <exception cref="T:System.ArgumentNullException">
73: /// The <paramref name="info"/> parameter is null.
74: /// </exception>
75: /// <exception cref="T:System.Runtime.Serialization.SerializationException">
76: /// The class name is null or <see cref="P:System.Exception.HResult"/> is zero (0).
77: /// </exception>
78: protected ModelStateException(SerializationInfo info, StreamingContext context)
79: : base(info, context)
80: {
81: if (info == null)
82: {
83: throw new ArgumentNullException("info");
84: }
85:
86: // deserialize
87: this.Errors = info.GetValue("ModelStateException.Errors", typeof(Dictionary<string, string>)) as Dictionary<string, string>;
88: }
89:
90: /// <summary>
91: /// Initializes a new instance of the <see cref="ModelStateException"/> class.
92: /// </summary>
93: /// <param name="message">The message.</param>
94: public ModelStateException(string message)
95: : base(message)
96: {
97: this.Errors = new Dictionary<string, string>();
98: this.Errors.Add(string.Empty, message);
99: }
100:
101: /// <summary>
102: /// Initializes a new instance of the <see cref="ModelStateException"/> class.
103: /// </summary>
104: /// <param name="message">The message.</param>
105: /// <param name="innerException">The inner exception.</param>
106: public ModelStateException(string message, Exception innerException)
107: : base(message, innerException)
108: {
109: this.Errors = new Dictionary<string, string>();
110: this.Errors.Add(string.Empty, message);
111: }
112:
113: /// <summary>
114: /// When overridden in a derived class, sets the <see cref="T:System.Runtime.Serialization.SerializationInfo"/> with information about the exception.
115: /// </summary>
116: /// <param name="info">The <see cref="T:System.Runtime.Serialization.SerializationInfo"/> that holds the serialized object data about the exception being thrown.</param>
117: /// <param name="context">The <see cref="T:System.Runtime.Serialization.StreamingContext"/> that contains contextual information about the source or destination.</param>
118: /// <exception cref="T:System.ArgumentNullException">
119: /// The <paramref name="info"/> parameter is a null reference (Nothing in Visual Basic).
120: /// </exception>
121: /// <PermissionSet>
122: /// <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="*AllFiles*" PathDiscovery="*AllFiles*"/>
123: /// <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="SerializationFormatter"/>
124: /// </PermissionSet>
125: [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)]
126: public override void GetObjectData(SerializationInfo info, StreamingContext context)
127: {
128: if (info == null)
129: {
130: throw new ArgumentNullException("info");
131: }
132:
133: // serialize errors
134: info.AddValue("ModelStateException.Errors", this.Errors, typeof(Dictionary<string, string>));
135: base.GetObjectData(info, context);
136: }
137: }
The exception action filter has to intercept ModelStateException exceptions and return the error in a predefined format, so the client's able to uniformly consume it. This is the code that I'm using:
1: /// <summary>
2: /// Represents errors that occur due to invalid application model state.
3: /// </summary>
4: [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false)]
5: public sealed class HandleModelStateExceptionAttribute : FilterAttribute, IExceptionFilter
6: {
7: /// <summary>
8: /// Called when an exception occurs and processes <see cref="ModelStateException"/> object.
9: /// </summary>
10: /// <param name="filterContext">Filter context.</param>
11: public void OnException(ExceptionContext filterContext)
12: {
13: if (filterContext == null)
14: {
15: throw new ArgumentNullException("filterContext");
16: }
17:
18: // handle modelStateException
19: if (filterContext.Exception != null && typeof(ModelStateException).IsInstanceOfType(filterContext.Exception) && !filterContext.ExceptionHandled)
20: {
21: filterContext.ExceptionHandled = true;
22: filterContext.HttpContext.Response.Clear();
23: filterContext.HttpContext.Response.ContentEncoding = Encoding.UTF8;
24: filterContext.HttpContext.Response.HeaderEncoding = Encoding.UTF8;
25: filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
26: filterContext.HttpContext.Response.StatusCode = 400;
27: filterContext.Result = new ContentResult {
28: Content = (filterContext.Exception as ModelStateException).Message,
29: ContentEncoding = Encoding.UTF8,
30: };
31: }
32: }
33: }
The reusable end result
All our controller actions can now take advantage of this reusable functionality. The previously shown controller action now looks like this:
1: [HttpPost]
2: [HandleModelStateException]
3: public ActionResult Add(Person instance)
4: {
5: if (!this.ModelState.IsValid)
6: {
7: throw new ModelStateException(this.ModelState);
8: }
9:
10: // save the new person instance and go back to master view
11: Person result = this.Service.Add(instance);
12: return PartialView("Person", result);
13: }
Our client side functionality can now be packed into a simple application specific jQuery plugin that does ajax error handling and can be loaded as part of the general scripts on your master (as in master template) view:
1: $.extend({
2: appAjax: function(url, type, datagetter, onsuccess) {
3: /// <summary>jQuery extension that executes Ajax calls and handles errors in application specific ways.</summary>
4: /// <param name="url" type="String">URL address where to issue this Ajax call.</param>
5: /// <param name="type" type="String">HTTP method type (GET, POST, DELETE, PUT, HEAD)</param>
6: /// <param name="datagetter" type="Function">This parameterless function will be called to return ajax data.</param>
7: /// <param name="onsuccess" type="Function">This optional function(data) will be called after a successful Ajax call.</param>
8:
9: var execSuccess = $.isFunction(onsuccess) ? onsuccess : $.noop;
10: var getData = $.isFunction(datagetter) ? datagetter : function() { return datagetter; };
11:
12: $.ajax({
13: url: url,
14: type: type,
15: data: getData(),
16: error: function(xhr, status, err) {
17: if (xhr.status == 400)
18: {
19: alert(xhr.responseText);
20: }
21: else
22: {
23: alert("Server error has occured.");
24: }
25: },
26: success: function(data, status, xhr) {
27: window.setTimeout(function() {
28: execSuccess(data);
29: }, 10);
30: }
31: });
32: }
33: });
In your page, you can simply call it this way:
1: $.appAjax(
2: "Person/Add",
3: "POST",
4: function() { return $(this).serializeArray(); },
5: function(data) { // consume data }
6: );
This is the reusable model validation in Asp.net MVC applications using Ajax calls and jQuery on the client side. If you have any further questions or suggestions please leave a comment. And don't forget to vote on this content.
Thanks!! Exactly what I needed.
ReplyDeleteOne question... While debugging, how do I throw ModelStateException to the browser only? Right now when the exception is thrown in the controller Visual Studio breaks execution to notify me and I have to resume for my controller to send the response to the browser.
You can control whether Visual Studio debugger breaks on certain unhandled exceptions. Either go to menu Debug > Expceptions... or press Ctrl+Alt+E. In the dialog that opens you will have to add your custom exception (include the whole namespace tree with the exception class name - same as other exceptions that are already defined there) and UN-tick "User-unhandled" checkbox of this particular exception. You can read about this functionality on MSDN: http://msdn.microsoft.com/en-us/library/038tzxdw.aspx
ReplyDeleteThis is awesome code...I implemented it almost verbatim.
ReplyDeleteOne change I would make is to the Message property of ModelStateException:
public override string Message
{
get
{
StringBuilder sb = new StringBuilder();
foreach (string error in this.Errors.Keys)
sb.Append(this.Errors[error]).Append("
");
return sb.ToString();
}
}
That way you can see all the errors at once...I display xhr.responseText at the top of my form as a summary of all the errors that need to be fixed.
@Anonymous: If you need to display all the errors than that is the right thing to do of course.
ReplyDeleteBut as I see you're joining those errors with spaces. You could as well just use string.Join method instead and accomplish the same task. Internally it doesn't use StringBuilder class but character buffer which is likely even faster than your code. So...
return string.Join(" ", this.Errors.Select(e => e.Value).ToArray());
This is a one liner and also uses a bit more contemporary LINQ query. You could do a similar thing by using Aggregate which is rather seldom used. I know I haven't used it yet.
Excellent article. Do you by chance have a working sample?
ReplyDeletethat you are willing to share of course. :)
ReplyDelete@Steven: application that's currently in development that integrates Asp.net MVC into Sharepoint uses exactly these classes. So yes I do have a working example. Unfortunately I can't show it to you...
ReplyDeleteWhat are your concerns? Maybe I can address them directly?
Only that I can't easily copy the code from your samples in the post above. :D I think your solution here is great.
ReplyDelete@Steven: Can't copy my code? I've actually added the "toggle code line numbers" to make it easier for you to copy code.
ReplyDeleteBy clicking on the link (above every code block), all those line numbers disappear and you can select and copy just the code without any unwanted junk.
If those links don't work for you, you can still copy the code (with line numbers included) and paste it into a text editor (Visual Studio or Notepad++) and use the multi-line editor capabilities to remove those line numbers all at once.
Refer to one of my previous comments about multi-line editor capabilities of modern text editors.
Hmm, dude, unless I'm mistaken, HTTP 400 errors are generated by web servers, which, in your case, is most likely IIS. Don't you consider it a violation of generally-accepted principles and practices, if it isn't your web server, but your program that fakes 400 errors on a whim, left and right and center? Please, enlighten me.
ReplyDeleteThis is a very interesting question. Let me try to explain reasoning behind my code.
DeleteEvery web application is running on a web server. One or another. And applications are run by the web server so they run in its context so to speak. Within. And if my application returns an HTTP error code this still means that server will send it. So they're still coming from the server. It is also impossible to expect of the server to understand the business processes of our applications so we may instruct it what to report back to the client. Server is what the word says... A humble and prompt servant.
However you look at it, these codes are HTTP standard. I don't see a particular reason why would I need to avoid them, when I have to tell the client exactly the same thing that 4xx codes are about: The 4xx class of status code is intended for cases in which the client seems to have erred. And when data validation fails this means that the client has erred. Client provided invalid values. So it is their fault and they should correct it.
I'll stick with these codes and not add an additional abstraction layer over my applications making them harder to maintain in the future. It's usually better to be practical and not overcomplicate most obvious things.
Just a question for you: What is the difference that Microsoft guys put into Asp.net MVC's routing code that also returns a 404 when route can't be resolved for whatever reason (even because of two matching controller actions). In the end it's still Asp.net MVC that reports the error and not IIS itself.
Feeling enlightened now? ;)
One more thing... Did you know that Twitter application returns a 420 error code that reads as: 420 Enhance Your Calm (Twitter). It's application that returns the code not the server itself. Servers only serve traffic. They can only orchestrate the very trivial and simplistic processes. Applications are almost always much more complicated in terms of processes.
Delete