Рекомендации разработчику
Для разработки plugin-программы понадобится Visual Studio. Рекомендуется производить билд сборок под версию фреймворка, идентичную используемой Oktell. В настоящее время версия 2.5 использует по умолчанию Framework 1.1 (не забывайте ставить SP1). Эта версия уже установлена с клиентским приложением Oktell и всегда доступна на клиентских станциях.
При сборке в других версиях необходимо гарантировать наличие соответствующего Framework на всех клиентских компьютерах. Также стоит помнить, что исполняемая среда CLR дает возможность подгружать только те сборки, которые скомпилированы в среде текущей или более младшей версии. Таким образом, например при использовании plugin-программ, созданных и скомпилированных в 2.0,необходимо переключить комплекс на использование Framework 2.0 (в конфигурационном файле сервера и всех клиентских станций ключ supportedRuntime), в противном случае эта plugin-программа не будет загружена.
Процесс разработки можно разделить на несколько этапов:
- Установить Visual Studio.
- Установить Framework.
- Создать решение (solution).
- Создать проект (project) типа «Windows Control Library» (или «Windows Class Library»).
- Создать в проекте класс управления.
- Объявить в теле проекта в доступном для класса управления месте делегат для события OnQuery.
- В теле класса создать заглушки для всех интерфейсных методов и событие OnQuery. Приложением Oktell будет создан один экземпляр класса, соответственно методы должны быть нестатическими (у объекта, а не у класса).
- Обеспечить возврат обще-модульными методами идентификатора, названия и версии.
Проект на этом этапе может быть собран, и результирующая подключена к Oktell. Из-за отсутствия каких-либо plugin-форм на этом этапе его дальнейшее полезное использование невозможно.
В целях удобства разработки и экономии времени рекомендуется начинать разработку с реализации поставленных задач: формы, алгоритмы компоненты и вся начинка. А уже потом налаживать интерфейс и XML-форматирование параметров и производить связывание с Oktell.
Для этого соответственно рекомендуется создать в текущем solution дополнительный тестовый проект типа «Windows Application», который будет обеспечивать вызов и отображение соответствующих форм и запуск соответствующих алгоритмов. Связать его статически с основным проектом и настроить его на работу с разрабатываемыми формами (это можно сделать как непосредственно, так и опосредованно через класс управления).
При необходимости использования внешних компонентов и/или алгоритмов, реализованных в отдельных библиотеках или сборках, стоит их подключать уже на этапе тестового использования при разработке. Точно также стоит сразу начинать выстраивать множественность сборок (множественность проектов), если в дальнейшем планируется разрастание plugin-программы в объемное приложение.
После того, как формы будут готовы, можно начинать осуществлять наладку интерфейса взаимодействия. Для этого вызовы, замкнутые на тестовый проект переводить в интерфейсные методы объекта управляющего класса.
К этому времени уже известно какие стартовые формы (точки входа) имеются у программы и можно начинать кодировать и описывать в соответствующем виде возвращаемых значений.
Для удобства работы с XML разработчикам предоставляется код пространства имен (namespace), в котором объявлены классы, преобразующие описанную в разделе «формат параметров» строку c XML-содержимым в объектную модель и наоборот. Формат работы с этими объектами будет рассмотрен отдельно в разделе «Объектная модель XML-парсера».
Разработчику следует знать: plugin-программа (главная сборка и ее окружение) будет загружена приложением Oktell в отдельный домен. Это дает определенные преимущества, но также накладывает некоторые ограничения. Это необходимо принимать во внимание там, где это играет роль. При регистрации программы администратор Oktell может установить загрузку в домен приложения, а также выбрать момент загрузки - на старте или на первом обращении. В любом случае plugin-программа, если она еще не загружена, подгружается в отдельный домен для доступа к невизуальным методам при регистрации и настройке сценариев и/или меню.
Все вызовы plugin-программы стоят в блоках try..catch, и возникающие исключения логируются в журнал Plugin. Вызовы происходят в главном потоке приложения. Это также необходимо принимать во внимание. В частности, создаваемые контролы получают очередь обработки в основном потоке приложения. Таким образом, все необработанные исключения, получаемые в интерфейсе plugin-программы, будут влечь исключения главного потока и выбивание приложения Oktell.
Для программ, подгружаемых в отдельный домен, может иметь смысл создание внутреннего потока обработки всех обращений из приложения Oktell и создание и запуск форм и контролов в этом отдельном потоке. Тогда исключения будут перехватываться в том домене, где осуществляет деятельность plugin-программа. Это не обязательная, и даже не рекомендованная стратегия. Однако рекомедуется оценивать перспективы возникновения исключений, и в целях снижения вероятности влияния исключительных ситуаций в plugin-программе на приложение Oktell чаще использовать перехват исключений (блок try..catch), особенно в местах обработки оконных событий.
Для программ, подгружаемых в домен приложения, создание контролов ОБЯЗАТЕЛЬНО должно производиться в потоке приложения, так как в противном случае их размещение в окнах приложения Oktell станет невозможным. Это не касается диалоговых форм, имеющих собственное окно. Ранее это не имело значения и для контролов, так как механизм их размещения в клиентском приложении Oktell совпадал с используемым для работы отдельного домена.
Уточнить, куда именно загружена plugin-программа, можно, например, сравнив пути Application.StartupPath и AppDomain.CurrentDomain.ApplicationBase. Для отдельных доменов базовым выставляется путь к папке, в которой лежит основная сборка.
Plugin-программа, загружаемая в отдельный домен, может иметь свой конфигурационный файл. При создании домена путь к нему определяется как к главной сборке с дополнительным расширением «.config».
Очень важно иметь обработку исключений (блок try..catch) в конструкторе управляющего объекта, в противном случае при попытке регистрации приложением Oktell будет выдаваться отказ по причине несоответствия интерфейса. Например, исключения может возникнуть при создании в конструкторе управляющего объекта других объектов, описанных в других сборках. При изменении классов, дополнении/изменении свойств, естественно могут возникнуть исключения. Рекомендуется их обрабатывать отдельно и уведомлять пользователя генерацией OnQuery.notify. Однако, подписка на OnQuery происходит после выяснения интерфейса. Поэтому возникающие в конструкторе исключения передавать через OnQuery нужно отложенным методом (например на первом вызове любого сервисного метода).
Рекомендуется не производить множественных инициализаций в конструкторе управляющего объекта. Не всегда его создание сопровождается работой plugin-программы в полную силу. В частности, при действиях в администраторских модулях (задание свойств plugin-формы при редактировании диалоговых сценариев, просмотр списка подключенных plugin-программ) происходит невизуальное взаимодействие клиентского приложения с plugin-программой; создание управляющего объекта производится с целью проверки интерфейса, а также запроса идентификатора и перечня заявленных в нем форм. При этом plugin-программа всегда загружается в отдельный домен с последующей выгрузкой. Разумеется, не имеет большого смысла создавать сетевые подключения, инициализировать визуальные формы и другие объекты, используемые при реальной работе.
Взамен, инициализацию визуальных форм рекомендуется проводить непосредственно при их вызове, невизуальные действия проводить при первом обращении на отображение диалоговой формы (или при вызове DoQuery.PluginLoaded).
В случае возникновения спорных моментов и проблем рекомендуется пользоваться стандартным лог-журналом (осуществлять в него запись в стандартном для Oktell виде через событие OnQuery).
Для удобств отладки рекомендуется иметь в программе флаги, при включении которых (возможно средствами интерфейса форм самой программы) осуществляется отображение или логирование всех вызовов, xml-параметров и возвращаемых значений.
В конфигурационном файле клиентского приложения Oktell в отладочных целях можно выставлять значение ключа Debug_PingErrorRestart в 0. Это исключит перезагрузку клиентского приложения по отсутствию или таймауту PING с сервером, что происходит в случае приостановки всех потоков во время отладки.
При необходимости разработчику доступен стандартный механизм отладки, для этого необходимо подключиться к процессу клиентского приложения Oktell, предварительно зарегистрировав в нем debug-сборку plugin-программы с дополнительным отладочным файлом.
