Новинки DIRECTUM 5.1 для разработчиков
При разработке DIRECTUM 5.1 мы с большим вниманием отнеслись к проблемам и нуждам разработчиков, модифицирующих нашу систему. Что из этого получилось, расскажем в статье.
Блокировки элементов разработки
Для защиты элементов разработки от одновременного изменения несколькими разработчиками создан механизм блокировок.
Теперь чтобы редактировать разработку, ее нужно заблокировать от изменений других разработчиков:
К блокировке можно добавить комментарий с помощью кнопки
Изменить блокировку. Например, указать, что блокировка
установлена для исправления замечания.
Для просмотра и работы с блокировками разработаны компоненты Все блокировки элементов разработки и Мои блокировки элементов разработки.
А в компоненте Экспорт разработки можно настроить фильтр по необходимым блокировкам. Например, можно выгрузить элементы разработки, которые были изменены в рамках определенной доработки системы или исправления замечаний.
Для тех, кому потребуются права на снятие чужой блокировки, создана привилегия «Управление блокировками элементов разработки».
По умолчанию механизм блокировки элементов разработки выключен. Включить его можно с помощью установки системы DevelopmentComponentLockEnabled.
Благодаря механизму блокировок вероятность потери изменений разработки при одновременной работе нескольких разработчиков в одной базе данных минимальна.
Диалог выбора произвольных данных из дерева
Прикладной разработчик теперь может программно создавать диалог выбора произвольных данных из дерева в список:
Для работы с данным диалогом добавлен интерфейс ITreeListSelectDialog, создаваемый с помощью новой системной функции CreateTreeListSelectDialog.
Прикладному разработчику необходимо учитывать особенности диалога:
- заполнять следует сначала доступные узлы, а только затем выбранные, иначе возникнет исключение;
- если при заполнении дерева не указать иконки для узлов, а признаку ImagesEnabled указать значение True, то узлы дерева будут заполнены со сдвигом вправо;
- если удалить из дерева выбранный элемент через объектную модель IS-Builder, то элемент также удалится и из таблицы.
Исправленные дефекты и реализованные пожелания
Исправлено множество замечаний к инструменту разработчика ISBL, например:
- в редакторе схем типовых маршрутов и стадий жизненного цикла документов реализован поиск блока по его номеру и наименованию;
- реализован автофильтр для реквизита Локализованная строка, часто используемого в компонентах разработчика;
- в мастерах действий элементы-переключатели теперь можно размещать в несколько колонок;
- в компоненте Сценарии добавлена кнопка Текст, теперь редактировать текст сценария можно, не открывая его карточки. А в карточке записи справочника Типовые маршруты добавлена кнопка События, теперь события ТМ можно редактировать, не открывая схему маршрута;
- при поиске по тексту вычисления выделенный фрагмент текста автоматически попадает в окно поиска.
Надеемся, что разработка кода на ISBL будет приносить удовольствие.
Александр, комментарии к блокировкам элементов разработки видны в истории элемента разработки? Было бы удобно отслеживать историю изменений
В истории сценария комментарий к блокировке видно - вместе с ИД пользователя - в колонке "Детальное описание".
История блокировки / разблокировки ведется во всех компонентах, где есть этот функционал, доступна через стандартное действие "История".
А нельзя автоматически вешать блокировку (если этот механизм включен, конечно), если объект перешел в состояние редактирования, и снимать все блокировки с элементов компоненты при ее закрытии? Постоянное включение/отключение блокировок для того, чтобы раз год не затерлись изменения, видится мне утомительным занятием. Как бы многие изменения наоборот направлены, чтобы меньше щелчков мышью делать (кнопка событий в ТМ, "Текст" в сценариях и т.д.), а тут такое наматывание пробега курсора для блокировок.
Смысл блокировки, в первую очередь, в долгосрочном блокировании, например, на неделю-другую. В случае, если вы снимаете блокировку каждый раз после закрытия элемента разработки удобнее вообще отключить этот механизм, чтобы, действительно, меньше кликов было. Как отключить - в статье написано.
А адаптировать механизм еще и для тех ситуаций, когда блокировка снимается каждый раз после закрытия элемента разработки, нельзя? Ну, чтобы он стал еще лучше?
Просто по аналогии с документами было бы странно, если бы блокировка не вешалась автоматически при открытии документа, и не снималась автоматически при закрытии документа. А мотивом блокировки документов было бы только долгосрочная блокировка.
Вставлю свои 5 копеек.
Мне кажется, что механизм блокировок лучше представлять себе как монопольный Check Out - Check In в системе контроля версий.
Т.е. не "я тут карточку открыл на 5 сек, чтобы 2 строки поменять", а как "я тут делаю фичу, и пока я ее не закончу - никому не трогать все что мне для нее надо". Т.е. блокировка=CheckOut. Когда фича закончена - снимаем разом блокировку со всего, это аналог CheckIn.
И развития хочется в сторону системы контроля версий - чтобы CheckOut реально создавал локальную копию элемента разработки, а в базу изменения ложились только при CheckIn.
Мне кажется, что тогда предложение Андрея очень органично уложится в дальнейшее развитие - в виде разрешения одновременного CheckOut разными разработчиками, и такой CheckOut можно будет сделать автоматическим.
Авторизуйтесь, чтобы написать комментарий