Рекомендации разработчику — различия между версиями

Текущая версия на 10:59, 1 апреля 2014

Для разработки plugin-программы понадобится Visual Studio. Рекомендуется производить билд сборок под версию фреймворка, идентичную используемой Oktell. В настоящее время версия 2.5 использует по умолчанию Framework 1.1 (не забывайте ставить SP1). Эта версия уже установлена с клиентским приложением Oktell и всегда доступна на клиентских станциях.

При сборке в других версиях необходимо гарантировать наличие соответствующего Framework на всех клиентских компьютерах. Также стоит помнить, что исполняемая среда CLR дает возможность подгружать только те сборки, которые скомпилированы в среде текущей или более младшей версии. Таким образом, например при использовании plugin-программ, созданных и скомпилированных в 2.0,необходимо переключить комплекс на использование Framework 2.0 (в конфигурационном файле сервера и всех клиентских станций ключ supportedRuntime), в противном случае эта plugin-программа не будет загружена.

Процесс разработки можно разделить на несколько этапов:

1. Установить Visual Studio.
2. Установить Framework.
3. Создать решение (solution).
4. Создать проект (project) типа «Windows Control Library» (или «Windows Class Library»).
5. Создать в проекте класс управления.
6. Объявить в теле проекта в доступном для класса управления месте делегат для события OnQuery.
7. В теле класса создать заглушки для всех интерфейсных методов и событие OnQuery. Приложением Oktell будет создан один экземпляр класса, соответственно методы должны быть нестатическими (у объекта, а не у класса).
8. Обеспечить возврат обще-модульными методами идентификатора, названия и версии.

Проект на этом этапе может быть собран, и результирующая подключена к 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-программы с дополнительным отладочным файлом.