Сегодня обратим внимание на один момент, по поводу которого ходит много слухов и споров. Только потому, что задача всегда имеет несколько вариантов решения, и все они имеют своё право на существование.

Программная сборка текста запроса

#разработка #запросы

Какую бы методику не выбрал разработчик, его главная цель – сохранить возможность открыть (хотя бы открыть!) текст запроса в конструкторе запроса.

Запрос на первом рисунке в конструкторе открыть нельзя, будет ошибка.

Какие варианты решения существуют?

1. Подмена комментария-шаблона. В месте подмены оставляем комментарий с уникальной «меткой», а в дальнейшем коде модуля, при выполнении необходимых условий, производит подмену этой метки на нужных кусок текста.

Плюсы:
Запрос работает всегда, даже если подмена не производилась (не было необходимости);
Минусы:
Если забыться и отредактировать запрос в конструкторе, то все комментарии слетят.

2. Подмена фиктивного параметра. То же самое, только в качестве мести подставляем параметр с уникальным именем.

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

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

Плюсы:
Можно редактировать запрос в конструкторе без потери данных;
Можно «конструировать» достаточно сложные запросы;
Минусы:
При работе с многострочными блоками текста появляется сложность в соблюдении точного соответствия теста шаблону;
В сложных запросах может быть трудно сориентироваться с тем, какой результат получится на выходе.

А какими методами пользуетесь вы? Есть ли у вас свои «фишки» по работе со сложными запросами? ))

БСП расширять - это вам не...

#разработка #расширения #БСП

С появлением в 8.3.11 возможности менять в расширении структуру данных, многие потирают руки в надежде получить счастье с конфигурацией поставщика "на замке". Но не спешите!

Есть одна досадная мелочь: БСП, при появлении нового объекта в расширении, пытается подключить его к модели сервиса, и требует указать для него значение разделителя области данных. Либо просто отказывается обновлять из-за них релиз. Да, при этом предлагает пути решения. Но!
1. В расширении нельзя поменять состав объектов в подписках на события;
2. В расширении нельзя изменить состав объектов для общих реквизитов.

Пока баг не пофиксили, выход такой:

1. В процедуру СвойстаКоллекцийОбъектовМетаданных() модуля менеджера справочника ИдентификаторыОбъектовМетаданных добавляем по строке для коллекций объектов, которые могут добавляться в расширении;
2. В процедуру КонтрольНеразделенныхДанныхПриОбновлении() общего модуля РаботаВМоделиСервиса добавляем наш объект в исключения.

Элегантный вариант универсальной функции определения наличия реквизита с нужным именем у любого объекта.
Данная версия реализации приглянулась тем, что в качестве значения-индикатора автор использует случайный UUID вместо «Неопределено», как это делают обычно. Получается действительно универсально! Ну и вишенка на тортике - возможность затребовать совпадение типа реквизита ))

#разработка #код

Использование префикса для параметров функций

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

Почему префиксы у параметров так важны:

1. При достаточно большом объёме кода в процедуре, префикс однозначно сигнализирует, что вы имеете дело с параметром, и не придётся лезть в объявление процедуры. Это комфортно.

2. Используя префикс, вы ограничиваете область видимости параметра рамками только этой функции, и уверены, что не испортите значение глобальной переменной или реквизита формы с таким же именем. Кроме того, когда-нибудь функция может переехать в другой модуль, и её контекст изменится. Это безопасно.

3. Используйте префикс, даже если функция состоит из одной строки. Всегда есть вероятность, что код будет эволюционировать, и тогда станет актуальным п.1. Это надёжно.

#разработка #код

Веб-клиент - не тонкий клиент

Думаешь накидал элементов на форму, проверил в тонком клиенте - и всё?? Как бы не так! Теперь запусти веб-клиент в браузере и приготовься удивляться.

1. Картинка в подвале реквизита ТЧ.
Если нужны итоги в подвале, то наличие картинки в том же реквизите оставит от цифр одни засечки, остальное улетит за экран.
Решение: отказаться от картинки. Но если хочется красоты, перенесите её в соседнюю колонку.

2. Та же беда с кнопками в режиме "Надпись+картинка".
Решение: кнопка лечится явной установкой ширины в её свойствах.

3. Программная установка активной страницы. Установка через "ЭтаФорма.ТекущийЭлемент" в веб-клиенте игнорируется.
Решение: установить текущую страницу у самого элемента "Страницы"

#юзабилити #формы #вебклиент

PS. Кейсы обнаружены на платформе 8.3.10 и в браузере Chrome

​Подстановка имени метаданного

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

#разработка #код

Сообщения, оторванные от реальности

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

#разработка #код #юзабилити

​Отбор данных по узлу обмена в ПВД

Не раз уже встречал правила обмена, в которых данные отбираются запросом в ПВД. И везде, в каждом ПВД (!), почему-то прописан поиск по коду для получения узла. Интересно, что они будут делать при тиражировании конфы или использовании этих правил в тестовом контуре? 🤔 А там коды узлов могут быть другие 🙂

Ловите двойной лайфхак 😃

1️⃣ Используйте недокументированный параметр УзелДляОбмена, в нём всегда хранится ссылка на узел, по которому идёт обмен в данном контексте (виден глобально в рамках правил);

2️⃣ Храните ссылку на узел в параметре конвертации. Даже если что-то изменится, правку достаточно будет внести в одном месте!

PS. Использование параметра УзелДляОбмена может затруднить запуск обмена в режиме отладки, может поэтому он не документирован 😉

#интеграция #ковертация #разработка

​Снижаем нагрузку на БД уменьшением числа читаемых таблиц

Когда в запросе необходимо получить две порции данных из одной таблицы, в зависимости от какого-то условия, часто делают обьединение двух запросов к одной физической таблице 🤦🏻‍♂️.
Но гораздо эффективнее прочитать таблицу один раз, а проверку условия и выбор реквизитов вынести в секцию выборки 👆

#запросы #оптимизация #разработка

🔨 git diff и cp1251 (настройка пейджера)

Перевожу один древний веб-проект с CVS на GIT, а он в кодировке cp1251, т.к. создавался во времена, когда UTF-8 только-только входила в обиход. Сконвертировать проект в UTF-8 пока нельзя, т.к. продуктовый сервер тоже из тех времен и тоже не поддерживает правильной кодировки.

Чтобы diff в консоли выводился в UTF-8, в GIT можно задать свою команду вызова пейджера вот таким образом:

git config --local core.pager "iconv -f cp1251 -t utf-8 | less"

т.е. перед вызовом пейджера less я вызываю iconv для перекодировки вывода и ее результат уже через пайп отдаю пейджеру.

Но вот незадача: комментарии к коммитам у нас в проекте в UTF-8, чтобы в веб-интерфейсе сервера управления репозиториями (у нас GOGS) они отображались правильно. А указанная выше настройка пейджера действует глобально на все команды, в результате git diff у нас показывает русский текст правильно, а git log — кракозябры.

Оказывается, для каждой команды GIT'а пейджер можно настроить отдельно, в частности, для решения моей проблемы в дополнение к указанной выше настройке нужно сделать:

git config --local pager.diff less

Т.е. для всех команд (diff, blame etc) выполняется конвертация из cp1251 в UTF-8, а для команды log конвертация не выполняется.

Пейджер можно вообще отключить, указав вместо команды пейджера значение false. Например, у нас список тэгов небольшой и удобнее, когда он сразу весь в консоль выводится, поэтому я пейджер для команды git tag отключил:

git config --local pager.tag false

Все настройки можно указать и вручную прямо в .git/config репозитория. Например, после выполнения указанных выше команд в этом файле настройки будут такие (все, что не относится к пейджингу, я пропускаю):

[core]
        ...
        pager = iconv -f cp1251 -t utf-8 | less
...

[pager]
        log = less
        tag = false

#Инструменты #Лайфхак

​"Конвертация" позволяет достаточно гибко определять данные для выгрузки и применять алгоритмы для конвертации практически чего угодно во что угодно.
⠀
Однако, функция ВыгрузитьПоПравилу() не так универсальна, как себя позиционирует. 🙄 Если вы скармливаете ей объект ссылочного типа, упакованный в собственную структуру данных, то такой источник должен быть типа "Структура", и никакой другой. 😬 При попытке передать в ПКО, скажем, строку ТЗ, будет ошибка, либо не удовлетворительный результат 😥
⠀
Дьявол кроется в функции ВыгрузитьПоПравилу(), часть которой представлен на рисунке 👆
⠀
#интеграция #ковертация #разработка

​Открытие формы записи регистра сведений

Часто ли вам приходится программно открывать форму существующей записи регистра? Думаю, нет. А рецепт этот не тривиальный, оттого и забывается быстрее. 👆

Вот вам в копилку 2️⃣ варианта реализации: первый с "ручным" формированием ключа записи, второй более нативный, но там лишний серверный вызов. Выбирайте сами 😊

‼️Ключевой момент - при формировании структуры-ключа должны быть перечислены все измерения и период, если РС периодический. 😎

#код #разработка

​Картинка в колонке динамического списка

Картинка в колонке таблицы - удобный и красивый приём визуально проинформировать пользователя о факте согласования или наличии файла.

Если в обычных формах мы это делали в обработчике "При получении данных", то в управляемой форме всё делается намного проще:

📌 Данные в колонке (ПутьКДанным) - это по-прежнему индекс картинки в коллекции

📌 Вид элемента меняем на "Поле картинки"

📌 А вот сама коллекция теперь указывается в свойствах элемента колонки, а не всей таблицы 😃👍

#разработка #формы #юзабилити