Опыт разработки скриптов для автоматизации работы в конфигураторе

Статья состоит условно из четырех частей:

• В первой я расскажу о предпосылках, которые приводят к необходимости использования дополнительных инструментов, кроме всеми нами любимого Конфигуратора.
• Затем расскажу, какие скрипты Снегопата и как решают ряд этих проблем.
• Далее обзорно я расскажу о том, как все это работает.
• И наконец, в качестве небольшого бонуса расскажу о моем небольшом эксперименте по реализации механизма, позволяющего автоматизировать работу в конфигураторе при помощи «скриптов», точнее обработок, на встроенном языке 1С.

С чем сталкивается разработчик?

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

Мы все являемся разработчиками и, наверняка, многие из нас уже работали и в других интегрируемых средах разработки. Так вот, сопоставляя свой опыт – мы видим, что в объеме и структуре современных конфигураций, по сравнению с 7.7 становится все сложнее и сложнее ориентироваться.

• Существующие прикладные решения стали огромными – по сотни тысяч строк кода, длииииинное дерево метаданных
• 1С:Предприятие 8.2 очень сильно выросло технологически, использует явно и неявно все самые современные технологии. Нам, как 1С-специалистам уже легко отвечать на троллинг фанатов других платформ –  1С и Оракал и Постгерс поддерживает, и под Линуксом работает и на популярных мобильных системах, и в облаке.
• От 100 000 строк кода – даже в простейших конфигурациях, вроде Библиотеки стандартных подсистем (дает базовый функционал) – даже самые простейшие конфигурации очень обширны по функционалу и имеют очень много кода.
• Разработчики 1С нас радуют развитием объектной модели. Все больше и больше появляется новых объектов. Объектная модель стала более технологичной – все больше в ней становится объектов, решающих «инфраструктурные» задачи (а не просто задачи предметной области). И как следствие — все больше низкоуровневого программного кода, который отвечает за организацию инфраструктуры, взаимодействие этих объектов. Но при этом сам язык остается процедурно-ориентированным, что накладывает определенные ограничения на организацию повторно используемого программного кода
• Средства по организации кода и метаданных несколько ограничены(ситуация практически не меняется с релиза платформы 8.0). То есть – средствами платформы мы, конечно, можем:
  • во-первых, группировать объекты метаданных в подсистемы,
  • а во-вторых – использовать общие модули для дополнительной организации кода. Но это все возможности, которые нам предоставлены по этой части. Больше нет. Мы в этом ограничены.

Способы решения

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

На сегодняшний момент существует два пути:

• Интенсивный путь – ждать каких-то решений по развитию платформы от фирмы 1С. Фирма 1С движется в этом направлении. В последних версиях улучшена подсказка, шаблоны и т.д. Но – дальнейших улучшений можно ждать очень долго.
• Экстенсивный путь – все в наших руках. Мы с вами вместе – Инфостарт тому пример, занимаемся разработкой каких-то внешних инструментов, то есть, идем  экстенсивным путем, расширяя инструментальную базу самостоятельно, не дожидаясь от вендора каких-то решений. Среди таких инструментов есть две категории:
  • Внешние инструменты. Также делятся на несколько категорий:
    • Работают с конфигурацией из режима «1С:Предприятие» или по COM. Представляют собой стороннее приложение, реализованное либо при помощи самой технологической платформы 1С:Предприятия, либо сторонними средствами, на других языках программирования. С помощью стандартных средств встроенного языка (и не только) предоставляют возможности быстро сориентироваться и проанализировать критичные вопросы работы базы данных – или разработать запрос к базе данных. Ярким примером является незаменимая подсистема «Инструменты разработчика» Сергея Старых.
    • Работают в пакетном режиме. Представляют собой решение по работе с кодом. Для того чтобы их применить, модули необходимо выгрузить во внешние файлы, после чего применить к ним обработку. Примером может являться конфигурация «Авто_Обновление измененных конфигураций 1С» компании «IzhTC»  (http://izhtc.ru/ ), которое в частности, распространяется фирмой 1С как «Автоматизированная проверка конфигураций». Этот инструмент – правда, в ограниченных возможностях, также может использоваться для юнит-тестирования.
• Инструменты, встроенные в конфигуратор. Снегопат – единственный известный мне инструмент, который позволяет для разработчика встраивать инструменты разработки в сам конфигуратор.

Во многих задачах достаточно внешних инструментов разработки. Но они ограничены в применении. Обычно их используют для массовой обработки каких-то объектов, для работы разработчика, которая требует контекст 1С:Предприятия – например, доступа к данным в режиме разработки запроса, чтобы его сразу отлаживать и т.д. А в случае, если мы хотим выполнить какие-то действия, которые влияют на исходный код, то, чтобы их применить, модули необходимо выгрузить во внешние файлы, обработать их и потом загрузить обратно. Это усложняет типичный workflow разработчика, потому что надо переключаться из конфигуратора в другое приложение, чтобы выполнить какую-то работу, а потом опять вернуться в конфигуратор и продолжить разработку в нем.

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

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

 

Инструменты встроенной разработки. Функционал

Итак, какие функции наиболее востребованы в той ситуации, в которой мы, разработчики, находимся:

• Возвращаясь к тем трудностям разработки, про которые я упоминал (огромные конфигурации, большое количество метаданных и большое количество кода) я дополнительно хочу акцентировать ваше внимание на том, что большую часть времени нам приходится работать с чужой кодовой базой. Это типовой код решений фирмы 1С, отраслевых решений или это код наших коллег.  Большую часть времени мы проводим в конфигураторе, разбираясь с ним. Значит – нужно иметь возможность быстро в этом коде ориентироваться, нужны средства быстрого поиска места дислокации объектов – процедур, функций, метаданных – и перехода к ним. Поэтому – отдельный класс задач, которые нам приходится решать – это навигация и поиск. Повышая скорость и удобство навигации и поиска, мы, тем самым, сокращаем свое непроизводственное время. Оставляем это время на решение текущей основной работы.
• Следующий класс задач – это задачи автоматизации работы с кодом на изменение. Очевидно, что написание некоторого программного кода часто представляет собой рутинную задачу, которую зачастую можно легко автоматизировать, тем самым сократив время на создание такого программного кода и сократив потенциальное число ошибок в нем. Генераторы кода, «умные» шаблоны облегчают жизнь при написании программного кода, освобождают время на творческие задачи. В этот класс задач входят также задачи по реорганизации существующего кода, т.н. «рефакторинг». Дело в том, что реализация нового функционала в существующей системе часто связана с задачами изменения, реорганизации существующего кода таким образом, чтобы новые функции можно было реализовать эффективно. Проведение рефакторинга также может быть автоматизировано и многие современные средства разработки имеют поддержку таких инструментов. Снегопат не исключение. Забегая вперед, скажу, что инструменты рефакторинга пока что решают только самые примитивные задачи, но, в связи с появлением в объектной модели Снегопата встроенного парсера кода 1С у нас появился очень большой задел для их развития.
• И, естественно – еще непаханое поле для задач по интеграции в конфигуратор других систем. Например, системы контроля версий. Или, например, интеграция системы контроля версий, встроенной в 1С (хранилища всеми нами любимого) с какими-то внешними системами (RequestTracker-ами и т.д.). Конечно, хотелось бы, например, как в других сторонних системах – прикрепить хук на какое-то событие, например, на событие размещения в репозитарий изменений, и тогда, одновременно с этим размещением можно было бы автоматически пометить тикет закрытым или просто отправить комментарий. Таким образом, мы бы объединили действие в двух системах, ну и сократили бы рутинную работу, чтобы разработчик не переходил обратно в RequestTracker и руками не закрывал эту задачу. Это могло бы существенно упростить workflow разработчика, опять же освободив время, повысив точность учета, контроль над изменениями.

 

 

Существующие скрипты для Снегопата

Далее – расскажу о скриптах, которые наиболее активно используются нашим сообществом. К каким-то из них я сам приложил руку. Но большую часть из них мы разрабатывали вместе с коллегами, с которыми мы общаемся на форуме Снегопата и на Инфостарте.  Итак, какие из перечисленных функций и в каком виде реализованы сегодня при помощи скриптов для Снегопата?

 

Навигация и поиск

Один из основных скриптов в этом разделе – это скрипт «Расширенный поиск». Как он работает?

Мы знаем – штатный глобальный поиск. Удобно, что он выдает результаты в виде списка. А вот в пределах одного модуля такой поиск нам недоступен. То есть – единственное, что мы можем в пределах одного модуля – это последовательно искать какие-то ключевые слова. А весь результат сразу – все найденные строки, в которых встречается совпадение, мы увидеть не можем.

Этот скрипт предоставляет такую возможность.

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

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

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

Теперь – вместо того, чтобы ждать, пока конфигуратор завершит выполнение глобального поиска по всей конфигурации, например, УПП (в ожидании курить/пить кофе), как это было при использовании штатного глобального поиска – мы можем продолжать трудиться над нашими текущими задачами (читать код, дальше что-то разрабатывать). Результаты в окно поиска будут добавляться в фоновом режиме. Это дает нам очень существенные преимущества.

Для быстрого поиска метаданных и навигации по ним реализован скрипт «Навигатор по метаданным», в исходном виде сделанный Евгением Мартыненковым и доработанный Александром Орефковым и Евгением Сосной.

В первую очередь – это «умный» поиск метаданных.

Мы все знаем, что в дереве метаданных нам стандартно доступен поиск по <Ctrl+F>, в результате которого осуществляется поиск по подстроке, и в табличную часть выводятся все объекты, в имени которых есть данная подстрока. Однако этим возможности стандартного поиска по метаданным ограничиваются.

При поиске метаданных с помощью «навигатора по метаданным» поиск тоже осуществляется по части подстроки, и при этом, что характерно, не важно, в какой части искомой строки находится эта подстрока – находятся все объекты, включая подчиненные (поиск подстроки производится по полному пути). Кроме того, можно далее через пробел ввести другие части полного пути. В результате – список сразу же фильтруется, нам легче и быстрее найти интересующий нас объект. Мы весь наш выбор делаем в одной подстроке.

Опять же – Евгений Сосна добавил одну очень интересную «фишку» в этот скрипт: найдя нужный объект, мы можем сразу просмотреть список процедур и функций его модуля. То есть — если в поисковой строке добавить двоеточие, то для текущего активного результата поиска будут показаны все процедуры и функции его модуля, и дальнейший набор поисковой строки будет фильтровать процедуры/функции по их имени, а затем позволит быстро перейти к нужному методу.

Штатными средствами как бы мы этого могли достичь? Мы в дереве метаданных нашли бы нужный объект, кликнули бы правой кнопкой мыши на этом объекте или каким-то образом вызвали контекстное меню. В этом контекстном меню опять кликнули бы какой-то пункт, чтобы открыть нужный модуль. В нем вызвали бы список процедур/функций… — то есть очень длинная последовательность действий.  Здесь все внимание акцентируется просто на наборе поисковой строки. Мы один раз вызвали диалог – далее мы просто набираем символы, какие нам надо. Причем не все (сокращаем). Опять же – очень сильно сокращает непродуктивное время.

Вроде – ерунда какая-то. Несколько секунд, на самом деле. А когда в течение дня этим занимаешься очень долго и много, то – оно реально отнимает много времени. А потери во времени – стресс для программиста.

 

Автоматизация работы с программным кодом

Переходя к следующей группе скриптов, сначала расскажу про скрипт расширения  шаблонов кода – Snippet.js.

Александр уже упоминал, что штатные шаблоны – уже очень мощная штука. Мы из видеороликов ребят из spec8.ru Евгения Гилева видим, как можно эффективно их использовать, как реально это помогает в работе. Хотя есть категория программистов, которые говорят, что использование шаблона сродни «копи-пасту», нельзя этого делать…Мне кажется, они не правы.

На самом деле использование шаблонов очень эффективно, потому что циклы и всякие стандартные конструкции мы регулярно набираем, надо уметь этим пользоваться.

Скрипт «Шаблоны кода» (snippets.js) расширяет возможности штатного механизма шаблонов, добавляя две простейшие «фишки»:

1. Возможность «обрамлять» шаблоном выделенную конструкцию. Например, как продемонстрировано на серии скриншотов, выделили текст – выбрали шаблон – выделенный блок обрамляется условной конструкцией «Если». Во время проведения рефакторинга такой прием часто используется, т.е., например, можно реализовать т.н. ExtractMetod (обернуть можно в любую конструкцию).
2. Вторая возможность совершенно случайно стала возможна благодаря тому, что Снегопат все текстовые окна интерпретирует как текстовые. В скриптах они все одинаково доступны. Таким образом, при подключенном скрипте «Шаблоны кода» становится возможным использовать шаблоны не только в окне редактора текстов, но также, например, в окне редакторе определения поля выборки в конструкторе запросов, или в редакторе запросов, который открывается в конструкторе запросов – т.е. там, где типовой механизм шаблонов почему-то не работает. Это позволяет использовать в окне запроса или редакторе определения поля выборки штатные шаблоны, а также – добавленные скриптом возможности по «обертыванию» выделенного кода. Где здесь эффект?  ЕСТЬNULL(<поле выборки>,0) – все знают, когда ручками приходится набирать, переключая раскладку… С этим скриптом все становится гораздо проще: выделили поле, вызвали шаблон, выделенный блок обернулся в ЕСТЬNULL. Кроме этого, курсор встал в позицию после запятой – нам остается только ввести альтернативное значение.

Вроде все – тривиальные вещи, но  так сокращает время… Не представляете.

Продолжаем рассматривать группу скриптов, решающих задачи автоматизации работы с кодом.

Скрипт по рефакторингу – refactoring.js. Сейчас есть примитивный, единственный вид рефакторинга, но он самый популярный – выделение метода.

Как он работает? Мы выделяем кусок кода, который мы хотим вынести в процедуру/функцию. Мы хотим упростить код (например, уменьшить количество условных конструкций в одной процедуре) или просто знаем, что этот кусок кода у нас повторяется. Выделили участок кода, вызвали макрос «Выделить метод».

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

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

Как я уже сказал – этот скрипт будет еще развиваться с учетом новых возможностей Снегопата по парсингу модулей.

Существует масса других скриптов, автоматизирующих работу с кодом. Эти скрипты в некотором смысле «невидимые» для нас и, зачастую, даже не имеют своего интерфейса – мы используем их просто нажатием комбинации клавиш для решения достаточно рутинных задач.

К таким скриптам относятся скрипты генераторов кода – конструкторов для заполнения свойств документов или справочников, скрипт «Автодополнение в стиле редактора Vim», скрипт «Авторские комментарии», скрипт форматирования кода и пр.

• «Механическое» автодополнение многими игнорируется, а зря. Этот скрипт появился еще в OpenConf-е, как очень эффективный способ набора кода в условиях отсутствия Intellisence. То есть – мы набираем первые символы слова и вызываем комбинацию клавиш.  Скрипт анализирует модуль – и по первым символам от курсора ищет нужное слово и подставляет первое попавшееся. Если подставленное слово не подошло – нажимаем комбинацию клавиш повторно – следующее подставляет. Что очень удобно – таким образом можно задействовать автодополнение даже в строках и в комментариях – где никакие другие средства автоматически не вызываются. Это калька с такой же возможности редактора Vim, который хорошо знаком всем тем, кто работает в Линуксе.
• Авторские комментарии, как и «Автодополнение в стиле редактора Vim» тоже тянется со времен ОпенКонф’а. Честно говоря, я не люблю авторские комментарии и считаю, что чаще это мусор. «Здесь был Вася. Я написал этот код» — в таком духе. Конечно, они позволяют организовать отслеживание изменений, но – я считаю, что для этих целей гораздо эффективнее использовать систему контроля версий. Так или иначе – по многочисленным просьбам он реализован. На Инфостарте статья была о том, как это сделать самому.
• Скрипт «Форматирование модуля» и «Расширение текстового редактора» добавляют несколько дополнительных команд по работе с текстом. В частности, «выровнять знаки равно», «выровнять по первой запятой», преобразовать регистр, а также решить множество других кропотливых рутинных задач.

Интеграция

Задачи интеграции с внешними системами – пока непаханое поле для реализации.

В настоящий момент реализована возможность просматривать и работать с файлами непосредственно в конфигураторе – банальный проводник файлов – скрипт «Внешние файлы».

И – опять же, Евгений Сосна, который у нас в последнее время выдает «на гора» кучу кода, реализовал для всех существующих модных систем контроля версий поддержку работы. Началось все с Fossil-а, закончилось – Bazaar-ом, Git-ом.

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

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

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

Сейчас мы с интересом смотрим на возможность, предоставленную нам разработчиками 1С:8.3 – выгружать во внешние файлы… Как они нам на партнерском семинаре намекнули, что, возможно, появится инструмент альтернативный конфигуратору. Ну… надеяться пока на ближайшее появление таких инструментов наверное, не стоит… А вот использование совместно с этим решением – выглядит вкусно. Потому что стандартное хранилище – оно достаточно медленное, поэтому работать с ним на больших конфигурациях бывает тяжело. И использовать альтернативную систему контроля версий – потенциально хороший вариант.

Как же все это устроено?

• Основным языком разработки является JavaScript, так сложилось. Хотя, на самом деле, скрипты можно писать на любом языке, установленном в вашей системе и поддерживающем технологию ActiveScripting, например VBScript. В данном случае все также, как было и есть в ОпенКонфе. PerlScript,  ActivePython – пожалуйста. Но вот – со Снегопатом так получилось, что все прикипели душой к JavaScript-у, наверное, потому что он сейчас считается самым модным, быстрым, мультипарадигменным, кросс-платформенным и функциональным.
• Естественно некоторые задачи требуют для своего решения организации интерфейса – для ввода каких-то входных параметров, редактирования настроек скриптов, отображения результатов их работы и т.д. Снегопат изящно решает этот вопрос, предоставляя возможность реализовывать формы скриптов в виде «обычных» форм и по той же технологии. Это дает большие преимущества, потому что формы скриптов выглядят точно так же как и любые другие окна конфигуратора. В OpenConf-е мы, например, не могли сделать для скриптов интерфейс «родными» формами – все наши надстройки все равно выглядели «чужеродно» — либо это была страничка HTML внутри конфигуратора, либо это была VBA –форма.
• И, наконец, третий момент – «точка доступа» для конечного пользователя скрипта – это его макросы. Макросы – это  методы скрипта без параметров, имена которых начинаются со специального префикса «macros».

 

Как выглядит простейший элементарный скрипт?

Простейший скрипт для Снегопата выглядит следующим образом.

Обратите внимание, вначале скрипта присутствует заголовок, сформированный из директив, обрабатываемых перед загрузкой скрипта самим Снегопатом. Другими словами, стандартные синтаксические конструкции языка JavaScript дополняются специальными директивами Снегопата, которые начинаются со знака $, которые объявляют элементарные свойства скрипта – под каким движком он должен работать, как называется (имя скрипта для пользователей), и его уникальное внутреннее имя.  И есть еще специальная директива для импорта в пространство имен этого скрипта других скриптов.

После загрузки скрипта Снегопатом все его макросы будут доступны в специальном диалоговом окне макросов, в той ветке, куда мы его загрузили, в группе, созданной с таким же названием, как оно указано в директиве $dname, в качестве подветки названия макросов там появляется.

Итак, в целом, для разработки скрипта для Снегопата необходимо знать язык JavaScript и объектную модель Снегопата.

Порог вхождения в разработку скриптов существенно снижается, если знать две вещи:

1. JavaScript поддерживает исходный код в формате UTF-8, а значит все идентификаторы можно писать на русском языке.
2. Очень многие объекты общего назначения, такие как массивы, структуры, соответствия, таблицы значений и т.п., а также многие методы глобального контекста 1С:Предприятия 8 могут быть использованы в ваших скриптах, причем в том числе в русскоязычном варианте.

Экосистема

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

Кроме доступа к своей объектной модели и глобальному контексту 1С:Предприятия 8, Снегопат реализует при помощи скриптов сервисные механизмы общего назначения, которые включены в его ядро. Это так называемые «Стандартные» библиотеки  — физически они находятся в каталоге  corestd относительно пути Снегопата.

Ядро

Расскажу немного подробнее про стандартные библиотеки Снегопата.

Ядро  — набор стандартных сервисных библиотек, основная часть которых является сервисными. Среди этих сервисных библиотек есть три, на которые обязательно необходимо обратить внимание: их директивы импорта позволяют в полной мере использовать в скриптах все основные возможности Снегопата:

• $addin global – предоставляет возможность доступа к глобальному контексту 1С.
• $addin stdcommands – предоставляет возможность доступа к командам 1С

$addin stdlib – предоставляют возможность доступа к общим «системным» функциям и плюс – с недавнего времени включена поддержка классического объектно-ориентированного программирования – ООП. Стандартно в JavaScript используется механизм прототипов, отличающийся от классического подхода к ООП. Это не всегда бывает удобно. Стандартная библиотека stdlib добавляет специальный объект, написанный Джоном Рейзигом – известным человеком среди программистов JavaScript – автором JQuery, который позволяет, программируя на JavaScript, создавать свои классы в более традиционном стиле ООП. 

 

Библиотеки классов и функций

 

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

 

В дереве скриптов такие скрипты размещаются в специальной группе «Подгружаемые библиотеки».

Библиотечные скрипты могут подгружаться в работающий скрипт динамически при помощи метода require() стандартной библиотеки stdlib.

 

Какие у нас на сегодня есть скрипты-библиотеки?

 

Во-первых, это библиотека ScriptForm.js.

 

Стандартная работа с формами 1С – она специфична. То есть – форма создается Снегопатом с модулем, но модуль этот мы использовать не можем, он предполагает какие-то конструкции на встроенном языке 1С. Модуль остается пустой. Мы все обработчики событий должны написать сами в JavaScript-е напрямую.

 

Из этого следует куча неудобств. Мы в форме должны ручками навесить обработчики событий. Потом сохранить форму, перейти в скрипт и т.д.

 

С помощью этого класса мы получаем следующую возможность – мы просто рисуем в дизайнере форм форму – сохраняем ее и переходим в скрипт. Наследуемся от класса, который предоставляет эта библиотека, и просто описываем обработчики событий. При этом преследуется принцип «Conventions over configuration» — принцип соглашения о наименовании обработчиков событий. То есть, теперь, для того чтобы задать обработчик события нажатия кнопки какой-то мы пишем имя кнопки, как оно задано в дизайнере форм,  — нижнее подчеркивание и имя события. Для формы обработчики событий должны называться как «Form_ИмяСобытия», для элементов управления – «ИмяЭлементаУправления_ИмяСобытия» и все!

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

 

Также – с помощью библиотеки ScriptForm.js автоматизируется работа с настройками – не надо вручную прописывать в дизайнере форм параметры сохранения настроек формы. При использовании этой библиотеки все это остается за кадром – мы просто наследуем от класса ScriptForm, указываем в его свойствах, какие реквизиты должны сохраняться как настройки (практически аналогично, как мы это делаем для форм обработок, указывая сохраняемые значения). Мы просто описываем, какие поля и в каком хранилище настроек должны сохраняться, вызывая в нужных местах метод сохранения или восстановления настроек, определенный в родительском классе.

 

Еще одна очень эффективная фишка, которую предоставляет нам эта библиотека – это наследование форм. Поскольку при этом  используется объектно-ориентированный подход, мы можем повторно использовать уже существующие формы, наследуя от них и переопределяя необходимые методы. То есть – мы можем повторно использовать один и тот же код. Кстати, в скрипте «Расширенный поиск»  глобальный поиск так и родился – просто пронаследовали исходный поиск и дописали  функцию поиска глобального.

 

Другая часто используемая библиотека – TextWindow.js.

Стандартно – Снегопат предоставляет возможность доступа к любому текстовому модулю, который мы открываем через интерфейс «ITextWindow». Но есть определенное ограничение. На изменение с этим модулем мы можем работать только через выделение текста. То есть – мы должны программно установить выделение на какой-то участок, потом изменить его, а потом снять выделение.

 

 

Это неудобно, многословно. Эта библиотека скроет эти детали и избавит от этой однообразной рутины, которую нам приходилось бы делать в каждом скрипте, который работает с кодом, при помощи удобного и хорошо знакомого нам, 1С:Специалистам, API объекта ТекстовыйДокумент.

 

Дело в том, что интерфейс работы с классом TextWindow абсолютно ничем не отличается от работы с обычным объектом ТекстовыйДокумент. Все понятно и просто. В том числе даже русскоязычные названия методов работают.

 

Куча других есть библиотек разной степени важности. Я о них сейчас детально говорить не буду. Это все надо пробовать на практике.

 

Эксперименты в конфигураторе

Замечание.  Эта часть презентации на сегодня потеряла актуальность. В настоящий момент лучшим и правильным способом писать скрипты для "Снегопата" на языке 1С является проект 1Script (https://bitbucket.org/EvilBeaver/1script/wiki/Home).

Я буквально за 2 недели до этой конференции загорелся реализовать все-таки свою идею – попытку написать скрипт на языке 1С для Снегопата. И это получилось!

 

Как такое может быть возможно?

 

На самом деле, ничего сложного нет – все элементарно и просто.

Выглядит это как обычная обработка 1С, в модуле которой мы, к примеру, написали такой код:

И оно работает так же, как в принципе и ожидается. То есть – в дереве макросов у ветки «Запуск обработок в Конфигураторе» появляются новые макросы, которые как раз и реализуют действия, запрограммированные нами в этой обработке. Правда, так уж реализовано, что все обработки, которые мы будем добавлять в Снегопат – все свои макросы будут отдавать одному и тому же скрипту «Запуск обработок в Конфигураторе» — RunEnterprise.js. Но это такая особенность.

 

 

Как это работает?

Все элементарно просто. Мы из специального служебного скрипта, который условно называется Загрузчиком, подключаемся через COM-соединение к специальной служебной информационной базе, в которую встроена всего одна единственная обработка и два метода в модуле обычного приложения. Обработка эта называется Информатор. Кто давно интересуется внутренностями 1С, и является пользователем форума 1С++, те про него наверняка слышали. Это очень крутая разработка, которая добавляет возможность рефлексии в 1С в программный код. 

 

Что такое «рефлексия»? Это возможность исследовать самого себя из программного кода. То есть – узнать свои методы, методы других объектов, с которыми работаем, перечислить их, вызвать и т.д. Штатно в 1С такой возможности нет.

 

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

 

То есть – Загрузчик – банально – инициализирует через COM-подключение, передает в него Designer – корневой объект всей объектной модели Снегопата и, конечно же, загружает обработки, которые размещаются в специальном каталоге. Информатор анализирует доступные методы, которые обозначены как макросы и дальше – передает список найденных в подключенных обработках макросов в список подключенных макросов Снегопата. А дальше – мы можем вызвать выбранное действие подключенной обработки, как обычно, из списка вызова макросов.

 

 

 

Какие преимущества такого подхода?

Вы хотите попробовать Снегопат, у вас есть какие-то идеи, которые вы хотели бы попробовать, но не хотите учить JavaScript. Это вполне нормально. У нас не так много свободного времени, чтобы еще изучать какую-то постороннюю технологию, которая не всегда может пригодиться. Можно попробовать таким вот образом. Естественно, такие скрипты будут менее эффективны в том плане, что на межпроцессное взаимодействие уходит какое-то время. Они будут медленнее, банально. К тому же, по всем другим показателям, движку 1С-ки не сравниться с движком JavaScript-а. JavaScript один из самых быстрых интерпретируемых языков.

 

Еще одна важная особенность, которая, я надеюсь, потенциально может вызвать интерес у сообщества – это повторное использование той массы обработок по работе с кодом, которая накопилась на Инфостарте. Теперь их можно будет использовать сразу из режима Конфигуратора, не переписывая на JavaScript. Во-первых, очень лениво их переписывать, конечно же. А написано и опубликовано очень много крутых вещей, которые прямо «просятся» работать в конфигураторе.

 

Например, часть функционала из Инструментов разработчика – по контекстной подсказке можно попробовать задействовать, ваши какие-то разработки тоже можно попробовать подключить.

Я в порядке эксперимента попробовал подключить всеми нами любимую «Разукрашку». Все получилось, все работает. Например, можно выделить код, вызвать макрос – откроется окно «Разукрашки» — мы только этот код скопируем.

 

Ограничения такого подхода

Про ограничения я уже частично упомянул. 

 

• Загрузка медленнее, естественно.
  • Во-первых, при большом количестве обработок это будет заметно при старте конфигуратора.
  • Во-вторых, наверное, при работе на каких-то алгоритмах.
• «Родные» формы обработки, к сожалению – только в модальном режиме, по вполне понятным причинам – это отдельный процесс совершенно. Форма создается в контексте отдельного процесса (для немодальных форм напишем обертку-прокси) – модальный режим устанавливает фокус на открываемое в рамках другого процесса окно формы.
• Ну и, поскольку опять же, вызываемая обработка выполняется в контексте другой информационной базы, то метаданные исходной базы напрямую недоступны, то есть – только через средства Снегопата.

 

Но тут у нас тоже потенциальная возможность. Мы можем использовать не какую-то стороннюю внешнюю базу, а производить COM-подключение к самой себе. И вот тут – потенциально, улучшение контекстной подсказки возможно, потому что мы в run-time можем какие-то объекты, модули анализировать с помощью того же Информатора и тем самым дополнять контекстную подсказку без парсинга модулей, т.е. анализируя вживую. Сейчас есть такая модная тенденция  в других живых современных средах разработки – код «наживую» изменяется – в run-time мы видим все изменения объекта, все свойства с помощью рефлексии получаем уже из проинициализированных объектов, их сущность. Какие составляющие, какие методы у них есть, какие свойства есть, какие доступные, сколько параметров и т.д. То есть – это проще, чем выполнять парсинг, потому что он уже выполнен системой.

******************

Приглашаем вас на новую конференцию INFOSTART EVENT 2024 INCEPTION.