Прошло полгода, как был опубликован цикл моих статей по поводу проблем разработки, и как следствие — способов хоть какого то решения проблем в плане их обхода. Одной из моих претензий к фирме «Новые облачные технологии» (далее НОТ), была крайне невнятная документация к API по разработке своих собственных расширений. С той поры, было выпущено 2 новых версии самих редакторов, и к каждой из них, было так же выпущено обновлённое руководство программиста. Если в версии 2.6 изменений можно сказать я не обнаружил, по сравнению с предыдущей версией 2.5, то вот намедни решил посмотреть, что же изменилось для версии 2.7, которая выпущена незадолго до нового 2024 года. И не скажу, что меня особо порадовали изменения в документации (и тем более в API), но в целом — вполне видна работа, хотя бы в направлении более внятного изложения идей заложенных программистами НОТ, в вопросах использования их API. Далее, я по пунктам изложу что я заметил ценного, и в конце выскажу своё сугубо субъективное мнение.
1.Подпись надстройки (п.2.2 нового руководства)
Не секрет, что вопросам безопасности в плане использования сторонних решений, стоит предавать большое значение. Не стоит на месте и НОТ. С помощью утилиты MOX входящей в состав обновленного дистрибутива, на основе Сертификата разработчика поставляемого службой поддержки «МойОфис», теперь можно подписать свою надстройку для безопасного распространения. Технология подписи в принципе проста, и понятно описана в указанном пункте документации. Вкратце в случае успешного подписания создаётся файл с расширением mox, который видимо следует размещать вместе с файлами дистрибутива надстройки. К сожалению, более подробно данный момент не раскрыт, что опять же, является, к сожалению, общим «больным местом» документации от НОТ.
2.Работа с документами (п.4 нового руководства)
Вот здесь прямо «душа возрадовалась», что толи мои «стенания» услышали, толи просто здравый смысл у технических писателей НОТ возобладал, но был добавлен реально довольно толковый раздел «Работа с документами», который достаточно подробно и последовательно, с примерами и даже иллюстрациями (!) описал логику работы. Причем, за что так же большое спасибо тем, кто переработал документацию, примеры разделяются отдельно для работы с текстовыми документами (п 4.1) и табличными (п.4.2), что очень важно, так как логика работы со внутренней структурой всё таки существенно отличается, в силу специфики самих форматов данных. Но и на этом праздник для программиста не оканчивается, так как далее следует описание работы с макрокомандами (п.4.3), и с отдельными очень важными для программистов работающими с табличными данными: именованными диапазонами (п.4.4), столбцами и строками таблиц (п.4.5), и работа с отдельными ячейками (п 4.6). Я настоятельно рекомендую ознакомиться с этой главой всем(!) кто хочет решать вопросы автоматизации в «МойОфис», причем начинать чтение документации именно с это главы, так как по прочтению, у вас сразу появится более‑менее внятная картина и о предоставляемых возможностях API, и о том, чего вы не сможете сделать на текущий момент, никаким способами, и о том, как вообще там всё функционирует. По сути, эту главу можно было бы выпустить как отдельный документ, и он наверное покрыл бы при ознакомлении процентов 80% вопросов типовых программистов, которые обычно возникают при начале работы с любым API, по типу таких как:
как создать\открыть\сохранить\экспортировать документ;
как внести правки в параграф (колонтитул, таблицу, ячейку и т.д);
как найти и изменить данные (изображения, графики и т. п.) в документе;
как работать со сводными (pivot) таблицами (о чем отдельно дальше);
как управлять внешним видом таблиц и их содержанием;
как придавать стили и форматировать отдельные элементы данных (параграфы, колонтитулы, ячейки таблиц и т.п);
достаточно много ещё каких других.
Так же хочется отметить, что подразделы проиллюстрированы достаточно подробно диаграммами рассматриваемых классов и их методов и свойств, что конечно позволяет концентрированно понимать возможности рассматриваемого раздела API:
Но, как уже само собой разумеющееся, и здесь не обошлось без «ложки дёгтя». К сожалению часть весьма нужной информации не упомянута! Например о том, что какие‑то типовые действия поддерживаются в API макросов, но не поддерживаются в API надстроек (например так и нельзя обновить принудительно документ, что приводит к тому, что информация после программного внесения изменений в документ в ряде случаев не отображается до момента ручного обновления внешнего вида документа). Или что нельзя в полной мере использовать API макросов добавляемых в документ надстройкой (такая возможность при этом есть), так как глобальные настройки окружения LUA для макросов и для надстроек различные но макрос при запуске из под надстроек будет использовать API надстроек, а не свой, и значит — просто не запустится должным образом (я пытался обойти описанную проблему с обновлением листа подобным образом внедряя в документ макрос и запуская его, надеясь что так сработает обновление документа, но «увы и ах»).
Да и примеры использования API всё — таки очень ограничены и по большому счёту малоинформативные, так как чисто надуманные и не рассматривают реальных задач, возникающих при автоматизации офисной работы. И очень не хватает в данном (или может быть отдельном, в конце документа) разделе какого‑нибудь реального учебного примера надстройки, от постановки задачи до её реализации в реальную надстройку.
3. Глобальные функции Document API (п.5 нового руководства)
Описывает глобальные функции доступные из API плагинов по созданию механизма поиска DocumentAPI:createSearch и создания скриптов DocumentAPI.createScripting, которые были ранее «зарыты» внутри описания справоных разделов API.
4. Справочник таблиц DocumentAPI (п.6 нового руководства)
Так же весьма важное изменение в документации! Теперь этот огромный справочный раздел по Api работы с документами руководства (ранее это был п.4) располагает свои подразделы не по какой‑то своей неведомой логике, а хотя бы в алфавитном порядке названия объектов DocumentAPI! Я раньше, например, вообще не понимал, почему справочник должен был начинаться с Диаграмм (4.1), потом перейти к описанию Именованных диапазонов (4.2), а продолжиться Макрокомандами (4.3) и т. д. Теперь всё логично, и хотя бы в плане того, что разделы идут по алфавитному порядку названий объектов DocumentAPI.Тем самым,поиск не приводит в ступор когда надо найти требуемую информацию: первым идёт AbsoluteFrame (6.1), потом AccountingCellFormatting (6.2), далее Alignment (6.3) и т. д. Согласитесь, так намного понятнее, если смотреть с точки зрения поиска информации. Правда, есть и своё существенное но — надо точно знать как класс API должен называться на английском, что не всегда очевидно по началу. Я бы на месте составителей документа, хотя бы добавил где‑нибудь справочную таблицу соответствия между названием класса в API и его смыслом на русском языке.
К сожалению, подробно просмотреть данный раздел я не успел (да и цели такой не было, честно говоря, так как сейчас я сосредоточен на работе в API конкурентном «МойОфис» отечественном пакете «Р7»), но успел заметить, что часть примеров использования методов объектов DocumentAPI, которые относились к описанию базовых основ работы с тем или иным классом, перенесены в раздел 4 «Работа с документами». Это как по мне так не совсем правильно, так как чаще всего пример использования ищется в разделе справочника, а не в описании API. Ну, в крайнем случае, можно было бы сделать перекрёстную ссылку на пример в этом разделе! Из чего делаю выводы, что раздел 4 нового руководства, в целом был ранее «размазан» по справочнику, а сейчас сгруппирован оттуда в отдельный раздел, что конечно более правильно, но примеры из справочника убирать не стоило, при этом.
5.Справочник функций EditorAPI (п.7 нового руководства)
Очень не понятно зачем, но почему то исчезли описания в целом весьма полезных функций: EditorAPI.getSelection и EditorAPI.setSelection. При этом, пояснений зачем их убрали, в тексте нет! Если их и правда убрали из API, то реально не понятно, каким образом программно делать выделение в документе? При этом, в примерах к некоторым классам и их функциям, например MediaObject:enumerate (на странице 194), эти функции остались! Чему верить не знаю, так как сейчас проверить нет времени.
Но в целом, данный раздел в API для меня остаётся как одно из наибольших разочарований, так как само API мягко говоря неполное. В нем нет такого огромного числа того, что требуется для нормальной работы с API редактора, что от обиды просто хочется иногда «разбить монитор!». И почему так сделано — вообще не ясно!
6. Справочник функций пользовательского интерфейса надстроек (п.8 нового руководства)
Главное разочарование прошлого года, которое увы никак не поменялось и с выходом новой версии. Все мои замечания и предложения, которые я направлял в техподдержку по вопросу расширения GUI для форм надстроек были проигнорированы от слова совсем. От разочарования, я даже забросил работу над написанием собственным редактором форм на базе Qt, который я сперва хотел было распространять на коммерческой основе, но потом понял что уж слишком слабые возможности в самом API надстроек, и поэтому пока приостановил этот проект.
Но вернёмся к ui. Хотя, в общем‑ то особо сказать и нечего. Всё осталось на том же уровне, то есть пока почти никак! И даже всякие недокументированные ранее, но полезные в работе моменты, по типу объектов Widget или свойств visible(), так и не описаны в новом руководстве (хотя уже и описаны мной в упомянутой в начале серии статей!).
Примеры в описаниях к классам, насколько я успел ознакомиться и сравнить, всё так же далеки от реальных задач, как и во всех прошлых руководствах. А если быть честным — то они тут просто не менялись! В общем — тут никакой работы не проведено, что ещё раз разочаровывает, так как, если судить по конкурентам из «Р7»,там с возможностями GUI для плагинов, всё более чем хорошо, так как строятся они на связке Chromium+JS со всеми плюшками фронтеэнда, какие только захочешь себе внедрить! Тут тебе и возможности библиотек или целых фреймворков доступно. Хочешь используй для GUI React, а хочешь чистый js+jQuery (или вообще чистый DOM+js). Да хоть через WebAsm полноценный 3D в формы подключай!
7. Остальные разделы
Ситуация аналогичная. Ничего особо нового в оставшихся разделах я, увы, не заметил. Вопросы создания своих модулей для расширений можно сказать что толком не рассмотрены. Да, на примере используемых стандартных по поддержанию регулярных выражений или UNICODE, можно попытаться подключить и какие то сторонние модули, вплоть до своего UI, коих на LUA не так уж и мало, но в реальности задача эта не такая уж и простая, и могла бы быть раскрыта как нибудь более подробнее, вместо описания упомянутых модулей!
Мои выводы
В целом, несомненно, работа по улучшению жизни для программистов офисной автоматизации под «МойОфис» проведена. Но, к сожалению, пока она носит скорее косметический характер и не охватывает большой пласт потребностей, прежде всего по визуальному взаимодействию конечных пользователей расширений и самих расширений (GUI надстроек). Остаётся пока только мечтать о нормальных формах или о возможности их внедрения внутри пространства самих редакторов.
Мне вообще не ясна позиция наших разработчиков в области замещения офисного ПО. Вот к примеру: в Р7 куда как лучше с работой с формами плагинов, о чем я упомянул выше, но прямо провал в некоторых вопросах с самими документами, таких например как работа со сводными (pivot) таблицами, а в «МойОфис», всё с точностью до наоборот. Вот бы взять и скрестить «ужа с ежом», и тогда глядишь бы можно было хоть как то решать задачи автоматизации, примерно того уровня сложности, как было доступно в офисных пакетах Microsoft ещё лет 20 назад. В чём же проблема такого отставания? Насколько я могу судить, она в том, что в разработке этих направлений участвует кто угодно из нанимаемых пачками программистов, но только не те, кто представляет себе какие реальные задачи стоять перед офисными работниками! А как следствие, малое представление о том, какие возможности надо предоставлять в первую очередь для их самостоятельного решения пользователям (или прикладным программистам) на местах. Увы, но похоже, пока это направление разработки даже не вторых ролях у всех разработчиков офисных пакетов в нашей стране.
