Breeze не поддерживает отправку displayName в качестве метаданных.

Одна из причин, почему мне действительно нравится работать с Breeze, заключается в том, что у меня много свободы в отношении метаданных, и я использую эту свободу, чтобы вручную предоставить модель объекта, включая валидаторы. Это прекрасно работает, но когда дело доходит до локализации сообщений для стандартных валидаторов, я заметил, что они используют имена свойств вместо отображаемых имен, потому что я установил отображаемые имена после того, как метаданные были загружены с сервера. Ну, дело в том, что я хочу избежать второго вызова сервера только для получения отображаемых имен. В качестве временного решения я изменил код бриза, чтобы разрешить получение displayName также из метаданных, отправленных с сервера, но опять же, мне не нравится менять источники бриза.

Есть ли другой способ получить метаданные за один вызов и предоставить их на ветер? Естественно, будет приветствоваться другая информация, такая как описание или водяной знак.

Последние версии предоставляют пользовательский узел, который я мог бы использовать, но тогда мне нужен какой-то перехватчик для каждого свойства, где я беру отображаемое имя и устанавливаю его для свойств данных и навигации. Есть ли способ сделать это?

Примечания: У меня есть пулреквест на github для проекта breeze, изменения минимальны.


person ioan    schedule 15.01.2014    source источник


Ответы (1)


Предположительно, вы читали о поддержке «настраиваемых» метаданных Breeze: http://www.breezejs.com/documentation/custom-metadata

Если это так, то все, что вам нужно сделать, это создать пользовательскую конечную точку на сервере, которая создает json в формате «настраиваемых метаданных» (вы, вероятно, будете использовать отражение на сервере для сбора этих данных), и вернуть этот json клиенту и тогда позвони

myMetadataStore.importMetadata(customMetadataFromServer, true);
person Jay Traband    schedule 15.01.2014
comment
на самом деле я использую стандартный способ получения метаданных (метод метаданных в контроллере, метаданные должным образом отформатированы, как ожидает ветер, в соответствии со схемой), но я подумал, что поскольку displayName все равно присутствует в DataProperty и NavigationProperty, это также может быть импортируется как таковой, а не с использованием свойства custom. Однако для описания, водяного знака и т. д. это правильное место, потому что они являются моими пользовательскими метаданными, но displayName также принадлежит бризу. - person ioan; 16.01.2014
comment
Я знаю, что метаданные, собранные из EF или NHibernate, не будут содержать displayName (но могли бы также собрать его из [DisplayAttribute] например) и именно поэтому это не было высоким приоритетом, но, скажем так, было бы неплохо :). - person ioan; 16.01.2014
comment
На самом деле существует ряд условий, при которых DisplayName не является частью метаданных (на ум приходит то, что большинство «настоящих» сервисов OData опускают его, наша реализация WebApi может захватить его, но на самом деле он не универсален) - person Jay Traband; 16.01.2014