TopSoft: опыт успешных решений

Доработайте протоколирование настроек, чтобы можно было в отдельном независимом окне видеть обращения к настройкам с возможностью тут же настройку изменить (без перехода по Ctrl-Enter).
А если еще как-нибудь увидеть результат срабатывания настройки (значение такого-то поля получилось: поле1 умножить на поле2 и разделить на настройку123), то цены этому не было бы.

Empyros писал(а):А если еще как-нибудь увидеть результат срабатывания настройки (значение такого-то поля получилось: поле1 умножить на поле2 и разделить на настройку123), то цены этому не было бы.

Всеми руками "за" такой функционал, т.о. получим простой и удобный метод определения действий по нажатию на конкретное поле/кнопку и т.д.

P.S.Понимаю, что все можно отсмотреть в Консоли управления, но КУ все ж-таки для тех.спец-ов, а не для, например, консультантов, которые саппорт видели только издали.

С таким же успехом можно просто поставлять исходные коды прикладной части.

Раз настроек стало много, то настала пора делать срезы настроек для разных бизнес-процессов.
В настоящее время есть два способа формировать разрезы используемых настроек.
1) Протокол использования настроек в интерфейсе. Реализован в ДО на продажу и Разноска хозопераций.
Позволяет собрать статистику по настройкам, используемым в интерфейсе и сохранить их.
Собранная статистика храниться в БД. Посмотреть можно или из интерфейса или
из модуля Настройка\Настройка\Настройки по интерфейсам.
Недостатки - требует программирования (хотя и небольшого) для каждого интерфейса.

2) Статистика обращений к настройкам. Формирует протокол обращений к настройкам.
Может вызываться практически из любого места Галактики. Не требует программирования.
Недостаток - не позволяет сохранить собранную информацию.
Как отмечалось выше - вызов этого интерфейса из модального окна по горячей клавише
не позволяет полноценно с ним работать. Надо будет доработать.

Можно доработать интерфейс "Статистика обращений к настройкам" так, чтобы:
- сохранять собранную статистику в БД;
- позволить пользователю добавлять-удалять из полученного разреза настройки и разделы;
- сделать экспорт-импорт разреза, для переноса в другие БД.
- добавить мемо-поле для описания разреза и отдельной настройки.
Можно исходя из нашего опыта сформировать разрезы для разных бизнес-процессов и поставлять
их в дистрибутивных БД, и обновлениях. А пользователь или сотрудник техподдержки сможет сам
формировать собственные разрезы настроек и через экспорт-импорт делится своим опытом с другими.

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

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

сейчас документация оторвана от кода и это создает определенные сложности именно в части соответствия, полноты описаний и актуальности. Поэтому документация на настройку должна наверное создаваться в коде ВИП-а примерно как документирование кода. В документации ее можно дополнить и поместить в help, но основная часть будет именно тут.

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

сейчас документация оторвана от кода и это создает определенные сложности именно в части соответствия, полноты описаний и актуальности. Поэтому документация на настройку должна наверное создаваться в коде ВИП-а примерно как документирование кода. В документации ее можно дополнить и поместить в help, но основная часть будет именно тут.

А мысль-то абалденная:
1)отказываемся от привычного всем help-а и связанного с этим "геморроя", как то, например, обеспечение работоспособности просмотрщика chm файлов (пусть и штатного, hh.exe)
2)помещать информацию по настройке в код VIP наверное не стоит... в коде и без того полно комментариев :), но ведь можно информацию по настройкам хранить в неких структурированных файлах, опять же с тэгами, и подгружать из них необходимую информацию непосредственно в интерфейсах редактирования настроек системы - оооочень удобная штука будет!
3)а ведь можно и в БД выделить специальные таблицы, для хранения информации по настройкам?!

продолжая мысль:)
было бы здорово организовать дополнительный интерфейс просмотра и определения настроек в похожем виде на wiki
прямо в статье, кликнул и изменил настройку.
а движков для встраивания wiki сейчас в избытке, так что с технической точки зрения проблем не должно возникнуть.

сразу будут доступны все указанные свойства (редактирование, поиск), при этом сами файлы Wiki можно действительно формировать рядом с ВИП-ом в компоненте и регистрировать в специальной БД.

на базе данной функциональности можно будет строить мастера первичной настройки специализированных решений по аналогии с мастером первичной настройки 1С конфигурации.

kroxa писал(а):продолжая мысль:)
...регистрировать в специальной БД.

это... а может нафик не надо специальную БД, может прям в рабочей базе...а то сиди потом и администрируй 2 разные базы??!