views:

218

answers:

2

I am trying to figure out how to notify the user which field failed to validate. I setup LINQ to SQL class datacontext to access a database from ASP.net pages. Since user input will be from by web interface forms and import from Excel files, i would like the write the validation logic in one place. The idea behind this is when i import from excel. I will collect the error messages for each row, and display a summary, somehow. A logical place seems to extend the class generated by LINQ to SQL. According to most documentation and examples, i should do something like this:

public partial class Customer 
{
  partial void OnTitleChanging(string value) 
  {
    if (!Char.IsUpper(value[0])) {
      throw new ValidationException(
       "Title must start with an uppercase letter.");}
  }
}

The problem with this approach is that validation will stop on the first failed field.

In Windows Forms Link1, if I define an ErrorProvider component in the form and set the DataSource property of it to your BindingSource the exception will be indicated by a red circle right to the validated control. The tooltip of this red circle will show the exception message.

Is there something similar for ASP.net pages? I am using the listview control and inline editing in the listview.


Updates: - I actually did something similar to what Nick Carver is suggesting. Link2 . Instead of throwing an exception, i record an error message.

public partial class PQSSClassesDataContext    
{
public partial class ErrorFeilds
  {
      private static List<string> Messages = new List<string>();
      public void AddErrorMessage(string message)
      {
          Messages.Add(message);
      }
      public List<string> GetErrorMessages() 
      {
          return Messages;
      }
  }
}

I am actually stuck on how to map the error message to the field. That's why i was looking for something like ErrorProvider. I am already using events instead of exceptions to record errors. Any idea how to mark the corresponding failed field from the codebehind file?

Any help appreciated.

+1  A: 

What we have done in the past is simply have an error collection on the DataContext, extend it just adding something like a List<ValidationError>. Then all you need to do is override SubmitChanges() and check if you have any validation errors, and decide to abort, throw them, handle however you wish really at that point...all before calling base.SubmitChanges()

We're in a ASP.Net per-request life-cycle, but if your Context is around longer make sure to clear the error list.

It's handy for your ValidationError class/objects to contain a reference to a common base or interface that all your classes implement so you can point to the object later from the error if needed. (e.g. get the ID for throwing the error labels or other info in the right place).

Example classes:

public class ValidationError {
  public string Message { get; set; }
  public IBase { get; set; }
}

public interface IBase {
  public long ID { get; set; }
  public DateTime DateModified { get; set; }
}
Nick Craver
+1, Very clean solution
JoshJordan
A: 

There is the ValidationSummary control, that works with the individual validation controls to show a list of errors. But the action of the WinForms ErrorProvider is performed in ASP.NET by the individual validation controls, which derive from the Label control

John Saunders