ASP MVC 2: атрибут регулярного выражения, работающий на стороне клиента, но не на стороне сервера

Question

[Required(ErrorMessage = "Date is required")]
[RegularExpression(@"^(((0[1-9]|[12]\d|3[01])\/(0[13578]|1[02])\/((1[6-9]|[2-9]\d)\d{2}))|((0[1-9]|[12]\d|30)\/(0[13456789]|1[012])\/((1[6-9]|[2-9]\d)\d{2}))|((0[1-9]|1\d|2[0-8])\/02\/((1[6-9]|[2-9]\d)\d{2}))|(29\/02\/((1[6-9]|[2-9]\d)(0[48]|[2468][048]|[13579][26])|((16|[2468][048]|[3579][26])00))))$", ErrorMessage="Date is not valid must be like (dd/mm/jjjj)")]
public DateTime Startdate{ get; set;}

Проверка на стороне клиента работает отлично. Так что, похоже, JavaScript может успешно понять мое регулярное выражение. Но когда я делаю обратную передачу, и вызывается modelstate.Isvalid ().

Моя дата больше не действительна. Поэтому я предполагаю, что когда .NET выполняет сопоставление с regEx, оно не совпадает.

Мой вопрос: почему это регулярное выражение совпадает на стороне клиента, а не на стороне сервера?

Answer 1

Это происходит, когда вы выполняете передачу данных обратной передачи первой, и он не может проанализировать значение DateTime. Кстати, не стоит помещать атрибут RegularExpression в класс DateTime. Имеет следующий код

public override bool IsValid(object value)
{
    string str = Convert.ToString(value, CultureInfo.CurrentCulture);
    if (string.IsNullOrEmpty(str))
    {
        return true;
    }
    Match match = this.Regex.Match(str);
    return ((match.Success && (match.Index == 0)) && (match.Length == str.Length));
}

, поэтому Convert.ToString (значение, CultureInfo.CurrentCulture) никогда не будет соответствовать вашему регулярному выражению, поскольку у него тоже будет часть времени.

Вам лучше использовать String вместо datetime.

Answer 2

Возможно ли, что правила проверки на стороне клиента фактически не применяются? Вы проверили, что обязательный атрибут работает как положено? Вы должны быть в состоянии использовать firebug для двойной проверки того, что регулярное выражение одинаково на стороне сервера, что все значения соответствуют ожидаемым и т. Д.

Кроме того, может быть, что вставленное значение проходит через регулярное выражение, но все еще не может быть преобразовано в datetime с помощью связывателя модели - это также может привести к ошибке модели.

Я не проверял ваше регулярное выражение, чтобы увидеть, что оно действительно делает, но если вы пытаетесь проверить, что ввод является действительной датой, используйте вместо этого DataTypeAttribute.

Answer 3

Я думаю, что если вы хотите проверить регулярное выражение, вы должны использовать:

public string Startdate{ get; set;}

и затем преобразовать его в DateTime на стороне сервера после привязки модели. Вы знаете, что дата должна быть предоставлена ​​в определенном формате, но подшивка модели не настолько умна и выдает ошибку. Если у вас есть DateTime после привязки модели, нет смысла проверять ее по регулярному выражению, не так ли? Сначала выполняется привязка модели, а затем проверка.