"Расширение модели метаданных"

[Алексей Калистратов]

Суть такая - можно ли получить на форме настройки поля сущности некоторый набор своих полей, которыми будущий администратор будет настраивать поведение этого поля?

Вот пара задач, для которых это нужно:

1. на форме много (больше 200) полей типа строка, к каждому из которых прилагается несколько типовых вариантов, которые пользователь видит по клику на поле и может выбрать один из низ, либо вписать свое значение в текстовое поле. Красивое (по моему ) решение вышло таким: в Description поля вбиваем эти подсказки, а скрипт на форме их все вытаскивает и через jquery.ui.autocomplete добавляет всплывающие подсказки ко всей этой туче полей.

Сваливать настройки в код не удобно по причине трудной навигации к ним - пользователю нужно будет знать имя поля, потом его найти в коде (а если добавить?), и не поломать остальной код рядом...

Грусть в том, что в UR12 это поле не может быть длиннее 217 символов (в UR11 лишь всплывало сообщение о превышении длины, но сохраняло длинные desciption'ы)

2. на форме куча слайдеров (input type=range), у которых у каждого свои подписи к значениям, свой min,max и цвета и т.п. - проблема та же. зашивать в код кучу этих настроек не есть гуд, и тут даже полем desciption не обойдешься - JSON пользователи не осилят, нужен интерфейс настройки

В качестве одного из решений (не очень хороших, т.к. приходится при создании поля менять два контекста), можно сделать рядом "Настроечную сущность", но как ее экземпляры привязать к полям целевой сущности?

Можно как-то плагин повесить "на добавление поля в сущность", который бы в настроечной сущности автоматически создавал пустую настройку с заполненным именем поля? В свежей версии Activity feeds ребята похоже как-то это делают - при добавлении сущности она сразу же появляется у них в настройках...

[Алексей Калистратов]

Вот еще подумалось - в принципе, хватит всего двух вещей:

1. Длинного поля description (ну хотя бы десяток килобайт, для ну очень сложных настроек)
2. Возможности прикрутить свой яваскрипт на форму настройки поля, который уже наворотит нужного интерфейса, а все данные свернет в json и в description положит. Это можно как нибудь без ансаппорта сделать?

[Anros]

Мне кажется, что решение через "Настроечную сущность" не такое плохое.

Ее экземпляры привязывать к полям можно по scheme name – два текстовых поля с именами сущности и ее поля.

Создавать экземпляр с пустой настройкой по умолчанию считаю не целесообразным, так как не для всех полей она нужна. Для редактирования этой сущности можно создать свой интерфейс, который может запускаться из риббона форм сущностей, например. Там считать метаданные сущности и отобразить список всех полей, для которых возможна настройка. При выборе поля для редактирования можно проверить создана ли настройка для него и если нет, то создать перед тем как открыть ее на редактирование.

Еще плюс в этом решении, что юзерам можно дать право на редактировании только этой сущности, не давая прав на кастомизаци CRM. Считаю, что не стоит давать права на кастомизацию CRM пользователям, которые не совсем понимают что делают.

[g.Naukovych]

Мы делаем следующее:
1 создаем сущность. настройки. для хранения настроек системы.
Неважно для чего они применяются.
Пример. я хочу, чтобы одно из полей было скрыто или отображалось.
Завожу настройку с названием определенным, на форме при загрузке получаю значения но этому заранее мне известному имени и в зависимости от значениявыставляю отображение.

Для вашей задачи подойдет следующее решение.
название настроек состоит примерно так. [EntityName].AutoComplete.[fieldName]
В самой настройке хранится значение.
Настроек с таким именем может быть несколько и в каждой вы пропишете свое значение.
Теперь код на форме.
НА загрузку добавьте метод получения настроек. Имя настройки должно начинаться с
[EntityName].AutoComplete таким образом для каждой сущности настройки будут свои.

Далее откусываете префикс [EntityName].AutoComplete и получаете для какого поля Ваша настройка. пишите ее в jquery и все работает.

Пример сущность настроек из 2х полей
Name: Lead.AutoComplete.name
Value: name 1

Name: Lead.AutoComplete.name
Value: name 2

Name: Lead.Contact.name
Value: Ivan

[slivka_83]

Цитата:

Сообщение от g.Naukovych

Завожу настройку с названием определенным, на форме при загрузке получаю значения но этому заранее мне известному имени и в зависимости от значениявыставляю отображение.

А "моргание" поле не напрягает?

[Артем Enot Грунин]

Я думаю, для решения вашей задачи не нужно привлекать метаданные. В вашем случае достаточно веб ресурса с настройками. Например, он может быть js или xml файлом. Где в каком-либо структурированном виде хранятся настройки для каждого поля.

[Алексей Калистратов]

Цитата:

Сообщение от Артем Enot Грунин

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

Веб-ресурс ведь нельзя показать на форме настройки поля?

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

В случае, если удастся расширить метаданные поля своими "мета-полями", то пользователю можно их показывать в тот же самый момент, когда он редактирует само поле. Это очень логично и пользователь доволен, что находит настройку там, где ей и место.

Вот, сделал proof-of-concept варианта с хранением json-a в поле description (оказывается его размер залочен на клиенте, а в базе оно большое и на сервере его не режут). Ансаппорт конечно.

Мне не удалось найти как штатно используется поле description в crm, подскажите, если кто знает?

[Артем Enot Грунин]

Алексей, вы меняете не метаданные поля, а настройки его отображения. Система допускает расширение формы за счет веб ресурсов. Вы можете расширять конструктор формы своими контролами, можете даже добавить свои кнопки на риббон редактора формы, например, сделать там кнопку настройки свойств выбранного веб ресурса или чего-то подобного. Если вам действительно, не жить не быть нужен продвинутый редатор ваших доработок, то я бы шел в этом направлении.

[Алексей Калистратов]

Согласен, этим решением с json'ом в description'e лишь меняю настройку отображения поля типа "Число", а хотелось бы по человечески расширить модель метаданных собственным типом поля, с собственным кусочком админки и пользовательским ui (и с более сложным хранением метаданных, не только сериализацией в текстовое поле)...

Я недавно в разработке MS CRM и до конца еще не понял, то ли любить его, за то, что на каждое "гвоздями приколоченное" архитектурное решение майкрсофта обязательно находится трюк с яваскриптом или ансаппортом, то ли ненавидеть, за эти же самые гвоздями приколоченные и штатно нерасширяемые возможности

[Артем Enot Грунин]

Ненавидеть. Люто. И написать свою систему с блекджеком и шлюхами.

[Likefire]

Цитата:

Сообщение от Артем Enot Грунин

Ненавидеть. Люто. И написать свою систему с блекджеком и шлюхами.

Вот тут двух мнений будет мало. Я, например, очень люблю MS CRM после общения с такими образцами как 1С и Navision.
А по поводу настроек, если конечно речь идет только о работе клиентской части, я бы посоветовал обратить свой взор в сторону JScript-оператора eval. Уж не буду напрягать и загружать примерами (для eval таковых на просторах сети немало), но это реально то, что доставляет при решении разных нестандартных задач.