Geum.ru

Ордена ленина институт прикладной математики им. М. В. Келдыша Российской Академии Наук

Вид материалаДокументы
3.Предлагаемые решения для организации взаимодействия DHTML-компонент
3.1.Модель программной структуры клиентского приложения
Подобный материал:
1   2   3   4   5   6

3.Предлагаемые решения для организации взаимодействия DHTML-компонент



В предыдущих разделах были описаны особенности взаимодействия DHTML-компонент в Веб-приложении с насыщенным пользовательским интерфейсом, где применяется режим асинхронной «сборки» документов в программной среде клиента. Представлена идея использования опробованного в архитектуре MVC-Smalltalk метода организации связей между компонентами, который позволяет избежать трудностей, возникающих при обычном, «комбинаторном» варианте реализации такого взаимодействия.

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


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

3.1.Модель программной структуры клиентского приложения



Одним из базовых инструментов DHTML-программирования, который разработчики активно используют при создании насыщенных интерфейсов Веб-приложений, являются средства визуальной компоновки документов на стороне клиента. Например, с помощью вложенных фреймовых окон (задаваемых посредством html-тегов frameset, frame и iframe) можно создавать составные документы, которые способны гораздо более рационально распоряжаться пространством внутри отдельного окна броузера по сравнению с обычными, простыми документами. В равной мере, осваивая возможности открытия дополнительных окон броузера (например, через обращение к функции window.open), можно эффективно использовать третье (оконное) измерение пользовательского интерфейса. В частности, именно эта техника часто используется в «настольных» системах для реализации сложных сценариев диалога с пользователем.

Применение таких средств заставляет нас радикально пересматривать представление о тех формах, которые может принимать выполняемое на стороне клиента приложение. Раньше, в классической модели Веб, можно было говорить о том, что приложение погружено в документ, а сама парадигма взаимодействия пользователя с серверной частью приложения сценарно состояла в прохождении через последовательность мини-приложений, которые в определенном порядке загружаются и выполняются на стороне клиента. Теперь, в интерфейсе Web 2.0, приложение может образовывать динамическую многомодульную структуру, в рамках которой операции добавления, удаления и замены модулей-документов в пользовательском интерфейсе составляют базовый функционал рабочего цикла приложения.

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

Одним из первых шагов, который следует сделать в направлении создания удобной архитектуры для разработки Веб-интерфейсов, является материализация программной структуры приложения в виде глобального объекта. Эта структура должна вестись параллельно представлению визуальной компоновки документов, которое поддерживается в модели DHTML. Она может, например, представлять собой простой массив ссылок на все документы приложения, находящиеся в текущий момент на стороне клиента. В функции глобального объекта, отвечающего за ведение этой структуры, должна входить возможность связывания дополнительной обработки при выполнении операций присоединения нового документа к приложению, изменения состояния готовности документа к работе (произошло событие onload), а также исключение документа из структуры приложения.

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





// application-manager.js


var application = {

windows: [window],

registerWindow: function(oWin){ ... },

registerWindowOnload: function(oWin){ ... },

unregisterWindow: function(oWin){ ... }

};


function OnApplicationUnload(){

for(var i=1; i< application.windows.length; i++){

var oWin = application.windows[i];

if(oWin != null && oWin.top == oWin)

oWin.close();

};

}

window.attachEvent(“onunload”,OnApplicationUnload);


Видно, что при запуске менеджера приложения создается специальный объект, который встраивается в контекст окна головного документа как значение атрибута window.application. Далее, в этом объекте создается массив для представления окон, в которых будут размещаться документы приложения. В момент старта в массиве сохраняется ссылка на само главное окно. Кроме того, объявляются методы, которые позволяют регистрировать изменение состояния прочих окон приложения – загрузку в них документов; наступление события, свидетельствующего об окончании загрузки, а также о завершение существования документа. Следует обратить внимание на добавленный в модуль application-manager.js обработчик события OnApplicationUnload, в задачи которого входит автоматическое закрытие всех дополнительных окон в момент завершения работы главного окна приложения.

Документы подключаются к менеджеру приложения и регистрируют себя в его структуре следующим образом:





// application-worker.js


var application = null;

if(window.top != window){

application = window.top.application;

} else {

try{

application = window.opener.application;

} catch(e){};

if(application == null)

window.close();

};

application.registerWindow(window);


function infoApplicationOnLoad()

{

application.registerWindowOnload(window);

}

function infoApplicationUnload()

{

application.unregisterWindow(window);

}


window.attachEvent(“onload”,infoApplicationOnload);

window.attachEvent(“onunload”,infoApplicationUnload);


В первой части скрипта решается задача подключения к менеджеру приложения. Если нам удается найти головную страницу, то в текущем окне сохраняется ссылка на объект application (таким образом этот объект оказывается разделенным между всеми окнами приложения). В случае, когда объект application не найден, а это означает, что окно каким-то образом вызвано вне контекста приложения, мы просто закрываем его программным образом (возможно при этом следует показать какое-то уведомление). Заключительная часть программы служит для уведомления менеджера приложения об изменениях в состоянии документа, загруженного в данное окно.

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