`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

GWT – разумный компромисс

Статья опубликована в №38 (655) от 7 октября

0 
 

С появлением AJAX «богатые» интернет-приложения (RIA, Rich Internet Application) похоже всерьез завоевали себе место под солнцем. Однако если в веб-программе набор интерфейсных элементов существенно беднее, чем в аналогичной настольной, и если при ее написании не были приняты специальные меры, позволяющие снизить эффект от неизбежной задержки при передаче данных по сети, то она вряд ли будет конкурентоспособной. А ведь современное веб-приложение требует реализации основной части кода на стороне клиента, и для решения таких задач нужны специальные инструменты.

GWT – разумный компромисс

Наверное, нет смысла выяснять, какой язык популярнее у программистов – Java или JavaScript. Совершенно понятно, что найдутся энтузиасты, беззаветно преданные JavaScript, но большинство разработчиков все же отдадут свой голос в пользу Java. Но как быть с двумя средними буквами в аббревиатуре AJAX, которые, как известно, означают именно JavaScript и никак не Java? Убедить производителей браузеров реализовать в своих продуктах поддержку Java в качестве языка сценариев, встраиваемых в веб-документ, – задача не из легких, если вообще разрешима. Возникает противоречие: писать программы хочется (по крайней мере, большинству разработчиков) на Java, но браузеры требуют JavaScript-сценариев. Однако наличие противоречия – одна из предпосылок плодотворной работы изобретательской мысли, находящей свое воплощение в новом творении. И оно создано уже достаточно давно. Это пакет GWT, или Google Web Toolkit, который можно условно рассматривать как кросс-транслятор с Java на JavaScript.

Несмотря на то что компания Google давно и плодотворно использует созданный в ее же недрах GWT, многие разработчики довольно скептически отзываются о нем. Причина, вероятно, в том, что они упускают из виду то, что привело к появлению в последнем предложении предыдущего абзаца слова «условно». Попытка непосредственно преобразовать работающее Java-приложение в его JavaScript-аналог, конечно же, обречена на провал. Вообще, вряд ли найдется реальная оконная Java-программа, которую удастся конвертировать в JavaScript-сценарий. Всякое инструментальное средство имеет собственную область применения, и наивно ожидать от него результатов за ее пределами. GWT – это не столько транслятор с одного языка на другой, сколько специальный инструмент разработки приложений, диктующий свои правила написания программ.

Первый шаг делает система

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

Пожалуй, самый трудный этап в работе каждого программиста – это первая программа. Этап чтения литературы (для кого длительный, для кого – короткий) позади, особенности нового языка или новой технологии, вроде бы, изучены, пора применить знания на практике. Но нередко случается, что хоть что-то да упущено, и созданная программа, пусть и предельно простая, упорно не работает.

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

applicationCreator <пакет>.<Имя>

В качестве имени задается любое допустимое для класса Java, что же касается пакета, то в этом вопросе система оказывается не столь либеральной. Последний в иерархии пакет обязательно должен иметь имя client. Так, на команду applicationCreator mypackage.Hello GWT отреагирует сообщением об ошибке и выполнит поставленную задачу только после того, как параметр будет изменен на mypackage.client.Hello.

В результате выполнения команды образуется иерархия каталогов, куда помещается ряд файлов. Обсуждать их все в рамках статьи не имеет смысла, но некоторые заслуживают рассмотрения. Прежде всего это основа создаваемого приложения – Java-файл с именем, указанным при вызове команды applicationCreator, содержащийся в каталоге client (в данном случае srcmypackageclientHello.java). Java-код, находящийся в файле, предельно прост, в нем определяются два интерфейсных элемента: кнопка и текстовая метка. С кнопкой связывается обработчик события, соответствующего щелчку на кнопке. При получении управления он изменяет текст метки. Один из вариантов текста – пустая строка, а другой... конечно же, знакомый всем «Hello, World!».

Еще один файл – HTML-текст страницы – находится в каталоге public (в данном случае это srcmypackagepublicHello.html). Однако естественная в других условиях попытка открыть файл с помощью браузера не принесет желаемых результатов. Ни кнопка, ни текстовая метка не появятся на экране. Причина в том, что содержимое Java-файла пока еще не преобразовано в JavaScript-код. Тем не менее не стоит спешить. Оказывается, что приложение может быть успешно выполнено и без данного шага. Сделать это можно с помощью оболочки – GWT shell. Она состоит из трех компонентов: протоколирующей консоли, встроенного сервера Tomcat (модификация Tomcat Lite) и браузера, поддерживающего специальный «гостевой» (hosted) режим. Такой режим браузера позволяет использовать в качестве обработчиков Java-классы, а поскольку код приложения (будь то Java или JavaScript) получает управление только при возникновении событий, становится возможным запустить его, не конвертируя Java в JavaScript. Чтобы упростить работу с оболочкой, GWT генерирует еще один командный файл, ориентированный на конкретное приложение (в рассматриваемом здесь примере он будет иметь имя Hello-shell.cmd). При его запуске откроется окно встроенного браузера, в котором появится содержимое созданного документа, включая интерфейсные элементы, определенные в Java-файле. Такой «гостевой» режим очень удобен: он позволяет отлаживать Java-код и преобразовывать его в JavaScript лишь тогда, когда будут устранены все ошибки и разработчик сочтет поведение программы удовлетворительным.

Для выполнения последнего этапа – конвертирования Java в JavaScript – также предусмотрен специальный командный файл. Наряду с другими он генерируется в процессе выполнения applicationCreator (в данном случае его именем будет Hello-compile.cmd). После этого наконец можно сделать то, что казалось естественным с самого начала – открыть в браузере файл Hello.html. Однако не стоит обращаться в каталог public; содержащийся там файл с этим именем предназначен для отображения в гостевом режиме, нужный HTML-документ помещается в соответствующий подкаталог каталога www (в данном случае путь к нему будет wwwmypackage.Hello). Найдя среди обилия файлов нужный Hello.html, можно убедиться, что окончательный вариант программы работает так, как и было задумано.

AWT? Swing? Не совсем...

Потратив несколько минут на генерацию первой программы и выполнение ее в различных режимах, разработчик, конечно же, захочет модернизировать ее и начнет, вероятнее всего, с пользовательского интерфейса. В пакете com.google.gwt.user.client.ui он найдет множество классов, предназначенных для создания интерфейсных элементов. Button, CheckBox, TextArea и другие подобные имена говорят сами за себя, одноименные классы входят и в известный всем пакет AWT. Но в com.google.gwt.user.client.ui также есть классы, функциональные возможности которых выходят далеко за пределы AWT, например Tree. Понятно, что ни с AWT, ни со Swing содержимое данного пакета не имеет ничего общего. Это GWT-классы, специально созданные для того, чтобы, с одной стороны, избавить разработчика от дискомфорта при их использовании, а с другой – обеспечить наиболее органичное конвертирование их в соответствующие HTML-элементы. Ведь нельзя забывать, что цель преобразования – отображение в окне браузера.

Если в знакомом всем Java API большинство классов и интерфейсов, предназначенных для обработки событий, находится в пакете java.awt.event, то в GWT они размещены в том же пакете com.google.gwt.user.client.ui. Наверное, такое решение вполне оправдано, ведь поскольку большинство событий генерируют именно интерфейсные элементы, логично поместить источники событий и их обработчики «рядом». Следует отметить, что реализуя средства поддержки событий, разработчики GWT не очень заботились о сходстве с Java. Конечно, модель делегирования осталась неизменной, но конкретные классы немного отличаются от Java-аналогов. Например, авторы GWT посчитали интерфейс MouseMotionListener лишним, метод mouseMoved() перекочевал из него в MouseListener и получил имя onMouseMove(), а mouseDragged() и вовсе исчез. Кроме того, методам обработки события вместо объекта <Тип>Event передается объект Widget, описывающий источник события, увеличилось число параметров. Однако данные изменения носят «косметический» характер, и специалист, имеющий опыт применения событий в Java, без труда разберется с новыми инструментами.

Асинхронное взаимодействие – «смысл жизни» приложения

Какое бы обилие интерфейсных элементов ни разместил разработчик на странице, приложение не станет по настоящему «богатым» до тех пор, пока в нем не реализовано асинхронное взаимодействие, позволяющее предельно сгладить нежелательный эффект от задержки, возникающей при передаче данных по сети. Неслучайно в AJAX именно первая буква расшифровывается как Asynchronous. Разработчики GWT уделили средствам поддержки асинхронного обмена данными существенное внимание, реализовав механизм удаленных вызовов процедур (Remote Procedure Calls, или RPC). Аббревиатура RPC хорошо известна тем, кто занимался организацией сетевого взаимодействия, однако в GWT удаленные вызовы процедур реализованы довольно специфически, поэтому предыдущий опыт мало применим в новых условиях.

Основа RPC – интерфейс RemoteService. Для того чтобы обеспечить обмен данными с сервером, разработчику необходимо выполнить следующие действия. Прежде всего он должен объявить интерфейс, который принято называть синхронным. Он является дочерним по отношению к RemoteService и содержит объявления методов, предоставляемых программой, выполняющейся на стороне сервера. Помимо него создается также интерфейс, называемый асинхронным. Его имя отличается от синхронного наличием суффикса Async. Так, если для синхронного выбрано имя MyService, то асинхронный должен называться MyServiceAsync. В составе асинхронного интерфейса объявляются те же методы, что и в синхронном, однако на них накладывается ряд ограничений. Во-первых, они должны иметь тип возвращаемого значения void, во-вторых, в их определении недопустимо ключевое слово throws, и, в-третьих, каждый метод должен иметь дополнительный параметр – объект, реализующий интерфейс AsyncCallback. В последнем определены два метода: onFailure() и onSuccess(). onFailure() вызывается в случае, если обработка запроса закончилась неудачей, в качестве параметра ему передается класс, инкапсулирующий информацию об ошибке. onSuccess() получает управление при корректной обработке, а в качестве параметра – данные, переданные с сервера. И наконец, третий элемент, создаваемый пользователем, – это класс, обеспечивающий функционирование серверной части приложения. Он должен быть подклассом класса RemoteServiceServlet и реализовывать интерфейс, соответствующий синхронному взаимодействию.

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

Формат XML не всегда уместен

В «классических» AJAX-приложениях данные, передаваемые клиентской программе сервером, чаще всего представляются в виде XML-кода. Происходит так совсем не потому, что XML-документы удовлетворяют всем потребностям. В ряде случаев уместно было бы обмениваться по сети объектом, однако его сериализация, т. е. «разворачивание» на сервере в последовательность значений и последующее «сворачивание» на стороне клиента, представляет собой слишком сложную задачу, требующую больших затрат времени и усилий. В GWT сериализация, как и многие другие процессы, происходит за сценой, а разработчику необходимо лишь выполнять ряд несложных условий. Для того чтобы объект, определяемый пользователем, стал сериализуемым, т. е. поддерживал последовательную передачу по сети, он должен реализовывать интерфейс IsSerializable (в Java для этой цели применяется интерфейс Serializable; в GWT также может быть использовано имя Serializable, которое является синонимом IsSerializable). Кроме того, в сериализуемом классе переменные экземпляра, не являющиеся константами или transient-значениями, также должны представлять собой ссылки на сериализуемые объекты, а среди конструкторов класса – присутствовать конструктор без параметров.

В короткой статье невозможно уделить внимание всем аспектам GWT. В частности, «за кадром» остались вопросы защиты, поддержки различных типов HTTP-запросов, использования формата JSON для передачи информации, взаимодействия с существующими JavaScript-библиотеками, настройки для работы в интегрированных средах Eclipse, NetBeans и Idea, а также многие другие важные детали. Однако даже рассмотренные выше основные вопросы позволяют составить представление о богатых возможностях GWT. Как и любой сложный инструмент, он требует внимательного изучения доступных средств и накладываемых ограничений. Того же, кто не пожалеет времени на это, GWT вознаградит простым, надежным, пригодным к сопровождению кодом. Затраченные усилия окупятся многократно.

0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT