 | Уровень сложности: средний Крейг Уолперт, старший инженер-программист, IBM
28.10.2009 Во второй, заключительной, части мы расскажем о том, как делать проект с расчетом на его дальнейшие модификации. Мы также остановимся на вопросах связывания и на создании шаблонов компоновки.
Примечание редактора: Эта статья - восьмая в серии статей о составных приложениях в разделе Lotus® сайта developerWorks®. Прочтите предыдущие статьи,"Приложение Lead Manager в IBM Lotus Notes V8: Общий обзор," "Разработка составных приложений: Проектирование компонентов," "Разработка составных приложений: Шаблоны проектирования," "Разработка составных приложений: Тестирование объектов," "Разработка составных приложений: Создание Eclipse-компонентов для IBM Lotus Notes," "Разработка составных приложений: Компоненты IBM Lotus Notes" и "Разработка составных приложений: Сборка составных приложений, часть 1."
Об этом цикле статей
Составные приложения - ключевой элемент в сервис-ориентированной архитектуре (Service-Oriented Architecture -- SOA) и в стратегиях контекстно-зависимой совместной работы (contextual collaboration). Эти приложения придают гибкость деятельности компаний и организаций, которым приходится быстро реагировать на изменяющиеся запросы конкурентного рынка. Составные приложения представляют собой совокупности компонентов пользовательского интерфейса, которые связаны между собой лишь в степени, необходимой для обеспечения межкомпонентного взаимодействия.
Компоненты можно многократно использовать в различных составных приложениях. Возможность комбинирования различных технологий в одном приложении имеет большое коммерческое значение. Она позволяет компаниям более гибко защищать существующие активы и распространять сферу их применения, быстро и без лишних затрат реагируя на возникающие потребности бизнеса с помощью приложений, создавать которые гораздо проще, чем в большинстве сред разработки приложений.
Такая слабая связанность компонентов в архитектуре составного приложения также позволяет различным группам, находящимся в разных местах, объединять усилия и взаимодействовать друг с другом. Например, одно подразделение может заниматься разработкой программы автоматизации бухгалтерского учета компании, в то время как другая группа работает над приложением по отслеживанию рынка потенциальных покупателей (приложение управления продажами). В составном приложении можно добавить в бухгалтерское приложение некоторые компоненты из приложения управления продажами для отображения актуальных бухгалтерских данных. Точно так же приложение управления продажами может включать в себя компоненты бухгалтерского приложения для предоставления финансовой информации по имеющимся активам. По мере разработки компанией все большего числа составных приложений возможности интеграции увеличиваются. Основная идея состоит в том, что полученное в итоге целое превосходит сумму отдельно взятых его частей.
Модель составного приложения уже знакома разработчикам IBM WebSphere Portal. Этот подход был распространён и на IBM Lotus Notes V8, что позволило разработчикам оформлять свои приложения Lotus Notes в виде компонентов составного приложения. Кроме того, в IBM Lotus Domino Designer была введена поддержка брокера свойств и реализована более интуитивно-понятная среда пользователя. Lotus Notes V8 также поддерживает вставку компонентов Eclipse. В составном приложении могут присутствовать любые комбинации компонентов Lotus Notes и Eclipse. Эти компоненты могут отображаться вместе в одном пользовательском интерфейсе за счёт "прозрачной" интеграции, или, если используется брокер свойств, полностью взаимодействовать друг с другом. Для определения составных приложений можно использовать редактор составных приложений Composite Application Editor или редактор шаблонов приложений WebSphere Portal Application Template Editor.
Введение
Данная статья -- вторая в серии, охватывающей различные аспекты сборки приложений. В первой статье мы писали об опциях, которые может использовать сборщик приложений при компоновке страниц и навигации по ним с целью добиться повышения производительности. Ниже мы рассматриваем вопросы проектирования страниц с прицелом на их изменение в будущем, стратегию связывания (wiring) и создание прототипа компоновки (потому что, как мы знаем, требования могут меняться). Часто требуется добавить или удалить компоненты и при использовании методов, описанных в этой статье, вы убедитесь, что вносить изменения совсем не трудно.
Предварительные требования
Предполагается, что читатель знаком с составными приложениями в IBM Lotus Notes, поэтому, возможно, будет полезно обратиться к разделу "Введение в составные приложения" Справки по IBM Lotus Domino Designer. Потом стоит прочесть первые три статьи данного цикла (см. выше примечание редактора), в которых как раз и содержится общий обзор и рассмотрены темы, связанные с шаблонами проектирования. Также обязательно прочтите статью "Разработка составных приложений: Сборка составных приложений, часть 1," в которой речь идет о компоновке и о шаблонах приложения в контексте сборки приложений.
Проектирование, предусматривающее модификации
Одним из преимуществ составных приложений является то, что их можно легко изменять для конкретных бизнес-потребностей, т.е. эксперт в определенной предметной области может настроить его в соответствии со своим рабочим процессом. Ниже мы предлагаем несколько методов проектирования, которые помогут вам предусмотреть последующую модификацию приложений при расширении бизнеса, который они обслуживают.
Широкие горизонтальные папки
В части 1 мы говорили о том, что возможность помещать наборы компонентов в папки имеет большой потенциал. Мы можем разместить на маленьком участке рабочего стола столько компонентов, сколько нам нужно. Компоненты на вкладках всегда можно развернуть до размеров целого экрана, поэтому такой способ развертывания позволяет приспосабливаться к различным стилям оформления компонентов. Добавлять или удалять компоненты при наличии папок с вкладками чрезвычайно легко, потому что все остальное в вашей работе практически не изменится. То есть, не надо будет переучивать пользователей.
Тонкие вертикальные колонки
Такая компоновка не позволяет разместить такое же количество компонентов разного размера, которое вмещают широкие горизонтальные папки. Установка стандартного размера для узких колонок может оказаться полезным методом высвободить место для компонентов, которые будут добавлены позже. Вертикальные колонки не могут избирательно выводить отдельные компоненты, как это делают горизонтальные папки, и они более подходят для таких дополнительных компонентов, которые должны отображаться постоянно.
Кросс-доменные компоненты (Cross-domain components)
Самая важная характеристика составных приложений - их способность интегрировать компоненты из различных информационных доменов. При четком планировании и проектировании такая интеграция легко достижима, хотя слияние независимых друг от друга задач и интеграция с приобретенными компонентами несколько труднее. Частая ошибка - включение дополнительных компонентов по принципу "просто потому, что они имеются". Конечно, хорошо иметь такие часы, которые показывают время для нескольких зон сразу, если для ваших пользователей эти часы не являются предметом первой необходимости, не имеет смысла засорять такими компонентами пользовательский интерфейс.
Еще одна проблема довольно часто возникает при использовании различных типов и пространств имен, потому что тогда вы не сможете связывать свойства из одного набора с действиями из другого. Для избежания этой проблемы используйте такие идентификаторы типов и пространств имен, которые не позволят вашим сборщикам приложений создавать бессмысленные связывания, а также обдумайте выработку стандартов для поддержки дальнейшего процесса разработки.
Иногда данные делают доступными в нескольких типах, чтобы обеспечить большую гибкость при последующей работе. Другой метод -- создать компонент-конвертер, который будет получать действия одного типа и выдавать свойства другого. Это может быть просто номинальное преобразование типов (например, из eMailAddress в SametimeID) без изменения данных или более сложная конвертация с использованием поиска (например, из EmployeeID в eMailAddress).
Стратегии связывания
Если вы просто поместите компоненты на рабочую поверхность, составное приложение не заработает; требуется связать все компоненты. Есть несколько способов связывания, но некоторые из них не имеют особого смысла. Приведем несколько примеров шаблонов проектирования, которые пригодятся вам в вашем приложении.
По потребности (As-needed)
Связывание "по потребности" - основной шаблон проектирования. Каждый раз, добавляя компонент, вы связываете его с нужным источником информации. Для страниц с малым количеством компонентов этот подход - единственно нужный. Если компонентов мало, как и свойств и действий, тогда все, что вы будете связывать, будет иметь какой-то смысл. Когда ваши приложения разрастутся, в них будет больше компонентов, страниц и связываний, могут возникнуть проблемы.
Многие действия имеют каскадный эффект и требуют вовлечения дополнительных свойств. Некоторые свойства срабатывают только при изменениях величин, другие при изменении ввода. Возможно также построение бесконечных или рекурсивных циклов. При связывании "по потребности" старайтесь использовать как можно меньше связываний, тогда в дальнейшем у вас будет меньше проблем при увеличении числа компонентов, страниц и связываний.
Изнутри -- наружу (Inside-out)
В обычной компоновке, когда у вас имеется несколько доменоцентрических компонентов и несколько периферийных компонентов контекста домена, часто используется шаблон связывания, задающий направление движения от центра к периферии. Контекстуальные изменения при переходе между страницами по перекрестным ссылкам, осуществляются при внесении изменений или смене выбранных объектов в центральных компонентах. После инициализации они активируют свойства, содержащие величины параметров в том информационном блоке, который они представляют. Эти свойства затем передаются к периферийным компонентам, а те используют их в качестве индекса для тех данных, которые они выводят. Иногда имеется и третий уровень, в котором данные, выведенные одним периферийным компонентом, используются другим. Но чаще поток данных направлен изнутри -- наружу, т.к. такое связывание легче для сборщика и понятнее пользователю.
Сохранность контекста (Context preservation)
В приложении, управляющем сложным контекстом, использование перекрестных ссылок между страницами для передачи единственной величины =- это еще не задание полного контекста. В таких случаях используют компонент-агрегатор, о котором мы писали в одной из предыдущих статей данной серии, "Разработка составных приложений: Шаблоны проектирования." Для сохранности контекста между страницами этот компонент нужно задать в месте, которое будет доступным различным компонентам.
Вместо того, чтобы связывать свойство из передающего компонента непосредственно с получающим его действием в отображаемом компоненте, лучше связывайте свойство с действием для данной величины в компоненте-агрегаторе. Затем свяжите свойство агрегатора, соответствующего передающему (broadcasting) компоненту, с действием отображаемого компонента. Этот метод гарантирует сохранность контекста, несмотря на то, что компонент будет задействован во всех передачах данных.
Пример: Предположим, что компонент Lead Manager CompanyBrowser осуществляет передачу свойства CompanyID, и вам нужно связать его с действием showCompany в компоненте CompanyDetail. Свойство CompanyID можно связать с действием setSelectedCompany компонента-агрегатора. Тогда действие showCompany компонента CompanyDetail будет извлекать свойство getSelectedCompany из компонента-агрегатора.
Используя компонент-агрегатор в качестве центра обмена информацией о модификации данных, ваше приложение будет гарантированно использовать самые новые контексты для всех отслеживаемых величин.
ПРИМЕЧАНИЕ: В Lotus Notes 8.0.1 появился новый инструмент, который позволяет одновременно просматривать все связывания в целом приложении. Со стандартной страницы связываний этот инструмент можно запустить, нажав на кнопку View All Wires (Отобразить все связывания). Это отображение позволит вам отсортировать информацию по страницам, компонентам или связанным свойства, –- что является удобным способом представить общую картину информационных потоков в приложении.
Еще одно усовершенствование в версии 8.0.1 -- возможность ослаблять (relax) проверку типов при связывания компонентов с опцией "Disable strict type checking" (Выключить строгую проверку типов) в окне соединений. Как правило, свойство можно связывать только с действием такого же типа. Но представим себе, что вы приобрели компоненты у производителя, который использует соглашения об использовании типов, отличное от вашего. Тогда во время сборки у вас есть возможность пропустить обычную проверку типов и связать свойство и действие разных типов. Только будьте осторожны с этим методом: если вы передадите компоненту величину, которую он не сможет обрабатывать, возможно возникновение непредсказуемых ошибок, поэтому постарайтесь вначале посоветоваться с разработчиками компонента.
Создание прототипа компоновки
Одно из чрезвычайно привлекательных преимуществ составных приложений состоит в том, что ваши разработчики могут сконцентрироваться на разработке компонентов, а специалисты в предметной области -- создавать на их основе приложения, нацеленные на решение конкретных задач. Как обычно бывает при разработке приложений, специалисты в предметной области должны иметь возможность сообщать разработчикам технических компонентов о своих потребностях.
И еще один плюс: компоненты, которые группа разработала для одного приложения, могут пригодиться другим группам в новых приложениях. Но возможно, что для увеличения гибкости компонента придется модифицировать сами приложения. Эта задача требует напряженной работы и иногда вызывает жаркие дискуссии внутри организации.
Обычно для представления информации об изменениях используют прототипы. Изменения соответствующего информационного потока и процесса не всегда легко заметить в традиционном представлении в режиме слайд-шоу. Для объяснения всем заинтересованным лицам того, зачем нужны изменения и какие преимущества они создадут, пригодится модель, которая способная выполнять некоторые действия, а вместо остальных имеет «заглушки».
В рамках нашего примера Lead Manager мы создали прототип Eclipse-компонента, который представляет несколько пользовательских интерфейсов в зависимости от модификации параметров дополнительных свойств. На рисунке 1 показан прототип первой страницы нашего примера Lead Manager, в котором сымитирован полный пользовательский интерфейс (через несколько экземпляров этого прототипа компонента). Наша модель не является рабочей, и нажатие на клавиши, как и выбор элементов списков, не приведет к изменениям на экране. Назначение прототипа - наглядно показать как будет выглядеть готовое приложение, дать возможность изучить сценарии его использования и заранее обнаружить возможные проблемы в проектировании.
Рисунок 1. Прототип для примера Lead Manager
Этот компонент-прототип имеет 8 режимов отображения:
-
Список (List). Основная область содержит список объектов, который может эмулировать представление или другие компоненты, созданные на основе таблиц.
-
Комбинированный (Combo). Основная область содержит выпадающий список объектов, и возможна эмуляция различных вариантов выбора.
-
Кнопка (Button). В основной области имеется горизонтальная полоса кнопок.
-
Кнопки по вертикали (VButton). В основной области -- вертикальная полоса с кнопками.
-
Информация (Info). В основной области имеется список некоторых величин с подписями, который может эмулировать форму в режиме "только чтение".
-
Редактирование (Edit). В основной области имеется список полей с подписями, который может эмулировать форму в режиме "чтение и запись".
-
Браузер (Browser). В основной области - компонент браузера, настроенный на конкретный URL-адрес, что может эмулировать связывание компонента с внутренним Web-приложением. Или, если он связан со статичным изображением, его можно использовать для графического отображения более сложного компонента.
-
Пустая страница (Blank). Основная область свободна и может использоваться для настройки компоновки.
Кроме того, что отображено в основной области, можно изменять имя, которое выводится на вкладке компонента, добавить дополнительный крупный заголовок в верхней части компонента и список кнопок с действиями, в виде горизонтальной полосы в нижней части компонента.
Прототип Lead Manager можно использовать для создания прототипов ваших собственных компонентов с другими часто встречающимися темами интерфейсов, которые могут пригодиться в разрабатываемом вами составном приложении.
Заключение
Наша первоочередная цель - создание высокопроизводительного составного приложения, но мы знаем, что приложения не статичны, они должны постоянно изменяться в соответствии с меняющимися потребностями бизнеса. Конечно, незачем каждый раз при добавлении новых компонентов перепроектировать все приложение. Говоря о компоновке страниц, мы предложили вам способы предусмотреть возможность модификации ваших проектов в дальнейшем. Кроме того, мы рассмотрели стратегии поддержки связываний между страницами вашего приложения, а в конце статьи привели простой компонент-, который позволят быстро создать прототип пользовательского интерфейса для обсуждения с заинтересованными лицами.
Ресурсы Научиться
- Оригинал статьи, Developing composite applications: Composite application assembly, part 2.(EN)
-
Начните с IBM Lotus Notes и Domino V8 -- техническое содержание.(EN)
-
Прочтите первую статью данной серии, "Приложение Lead Manager в IBM Lotus Notes V8: Общий обзор."
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Проектирование компонентов."
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Шаблоны проектирования."
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Проектирование компонентов: Тестирование объектов."(EN)
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Создание Eclipse-компонента для IBM Lotus Notes."(EN)
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Компоненты IBM Lotus Notes."(EN)
-
Прочтите статью с сайта developerWorks, "Разработка составных приложений: Сборка составных приложений, часть 1."
-
Прочтите статью с сайта developerWorks, "Что нового в IBM Lotus Notes и Domino V8."(EN)
-
Прочтите статью с сайта developerWorks, "Расширение возможностей работы с почтой в IBM Lotus Notes V8 с помощью Eclipse."(EN)
-
Прочтите статью с сайта developerWorks, "Интеграция данных IBM Lotus Notes с боковой панелью Lotus Notes V8 и панелью инструментов."(EN)
-
Прочтите статью с сайта developerWorks, "Расширение боковой панели и панели инструментов IBM Lotus Notes V8."(EN)
-
Прочтите статью с сайта developerWorks, "Использование пользовательского контекста в боковой панели и панели инструментов IBM Lotus Notes V8."(EN)
-
Начните с Помощи по IBM Lotus Domino Designer 8.(EN)
-
Найдите для себя ответы на странице developerWorks, посвященной составным приложениям Lotus.(EN)
-
Прочтите "Комментарий обозревателя к Lotus Notes и Domino 8."(EN)
-
Прочтите о Eclipse-проектах на сайте developerWorks.(EN)
Получить продукты и технологии
Обсудить
Об авторе | | | Крейг Уолперт (Craig Wolpert) - старший инженер-программист программы поддержки независимых производителей ПО в IBM Lotus Software. |
Выскажите мнение об этой странице
| |
