2013-03-18 5 views
2

Хотите узнать, знает ли кто-нибудь о возможности расширения или настройки Breeze, чтобы сервер возвращал дополнительную информацию в метаданные объекта? Я бы хотел использовать эти дополнительные данные, чтобы помочь с проверкой.Возможно ли распространять метаданные Breeze, полученные с сервера?

Предположим, у меня есть модель сущностей как и с некоторыми аннотациями данных применяется:

public class Person {  
    [RegularExpression(@"^$|^http\://[a-zA-Z0-9\-\.]+\.[a-zA-Z]{2,3}(/\S*)?", 
     ErrorMessage="The Website address does not appear to be valid.")] 
    public string Website { get; set; } 

    [Required(ErrorMessage="The Name field is required."), 
     MaxLength(150, ErrorMessage = "The Name field cannot exceed 150 characters."), 
     MinLength(5, ErrorMessage = "The Name field must be at least 5 characters.")] 
    public string Name { get; set; } 
    //... 
} 

Прямо сейчас, Breeze только перехватывает вверх MaxLength и необходимый валидатор на основе метаданных, которую он получает, так как это все, что поддерживает выход из коробки. Если Breeze может включать в метаданные информацию, описанную в атрибутах аннотаций данных на сервере, я думаю, что тогда Бриз сможет автоматически добавить дополнительные валидаторы акций клиенту EntityType (например, для RegEx, Range, MinLength, и т.д...). Это будет охватывать большинство основных случаев использования валидации. Или он также может позволить разработчикам проверять метаданные и извлекать полезную информацию, такую ​​как строка regEx, которую мы могли бы использовать, чтобы подключить собственный собственный валидатор RegEx.

Кроме того, существует ли способ включить Breeze значение атрибута атрибута ErrorMessage в метаданных, а затем использовать клиент бриза вместо требуемого по умолчанию и maxLength messageTemplates? Это означало бы, что вам нужно будет только определить сообщение об ошибке в одном месте на сервере и не нужно настраивать его для каждого объекта.

Я стараюсь не создавать и регистрировать кучу пользовательских валидаторов на клиенте, поскольку это похоже на основные проверки, которые могут быть выполнены Breeze автоматически.

Спасибо, Richard

ответ

0

Это большой вопрос.

Мы еще не сделали хорошую работу по документированию того, как сервер сериализует метаданные, но это должно появиться «в ближайшее время». Однако, если вы посмотрите на json, идущий через провод, вы заметите, что валидаторы сериализуются просто по имени. Затем это имя просматривается среди зарегистрированных валидаторов (или валидаторных фабрик) на клиенте, а затем добавляется к метаданным на стороне клиента. Таким образом, идея заключалась бы в регистрации вами «реализации» валидатора на клиенте с уникальным именем, а затем сервер ссылался на это имя при отправке метаданных с сервера.

Надеюсь, это станет яснее через неделю или около того, как только мы задокументируем, как создать свои собственные метаданные на стороне сервера, чтобы отправить их клиенту.

+0

Спасибо за указатели. Я посмотрю на это сегодня вечером. Было бы неплохо, если бы обновления doc обсуждались, как настроить метаданные для добавления дополнительных свойств (сообщение об ошибке, шаблон REGEx, minLength и т. Д.), Которые могут быть использованы для автоматического подключения реализаций проверки клиента. В то же время я буду с нетерпением ждать обновлений doc. – RWHepburn

0

Хммм, прошло год. Любые новости по этой теме? Я полностью согласен с RWHepburn в том, что определение всех правил проверки на стороне сервера и их доступность на ветру на стороне клиента будет отличной вещью. Это то, что нужны аннотации данных в EF - это упрощает!