Данный обзор ставит целью помочь руководителям проектов и программистам, не знакомым с технологиями Google Web Toolkit и Google App Engine, принять правильное решение об использовании или неиспользовании их в новом проекте.

Данный обзор не является введением в указанные технологии – для этого есть приличная документация на сайте google. Я ограничусь только определениями, чтобы понимать, какой стороне этих технологий будет уделяться здесь первоочередное внимание.

Определение 1
Google Web Toolkit или GWT является способом получения javascript (js) кода из java кода. Полученный таким образом js размещается на обычной HTML странице и исполняется после ее загрузки браузером.

Определение 2
Google App Engine или GAE – это среда, в которой могут выполняться сервлетные приложения. Его можно было бы назвать Application server, если бы это название не было занято для приложений J2EE. GAE предоставляет для  сервлетов ряд сервисов. GAE не может быть развернут и использован на отдельном сервере, только компания Google поддерживает сервера с этой средой, давая разработчикам возможность загружать туда свои приложения и предоставляя к ним доступ пользователям, т.е. hosting.

Обзор состоит из 2-х частей. Часть первая про GWT, вторая – про GAE.

Часть 1.

Ниже приведен список особенностей GWT, на которые следует обратить внимание при принятии решения об использовании его в проекте. Но перед этим я кратко сформулирую вывод – по нашему мнению (т.е. не только моему, но и других разработчиков компании), GWT целесообразно применять для реализации сложной логики и бизнес интерфейсов на стороне клиента. Для создания UI больше подходит javascript, html5, css3 и т.п., а также библиотеки типа JQuery и реализации AJAX с использованием JS. Использование GWT для создания UI оправдано только на этапе прототипирования или, если этот UI простой и не будет дорабатываться или изменяться в дальнейшем.

+ GWT использует для написания клиентского (исполняемого на браузере) кода язык java, а не js. Допускается также использование ограниченного количества классов из пакетов java.lang, java.util и др.. В документации имеется перечень этих классов. Так, если вам требуется объект со свойствами TreeMap, не нужно искать подходящую реализацию на js или писать ее самим – просто используйте известный java класс. Если вам требуется сложная логика, ее легче закодировать на java, чем js.

+ Поскольку java компилируемый язык, многие ошибки будут обнаружены на этапе компиляции, а не выполнения. Java более строгий, чем js, язык и это позволяет писать существенно более надежные приложения. В версии GWT 2.x используется синтаксис и классы из JDK 1.5 включая Generics.

+ GWT ряд имеет API для взаимодействия с сервером. Все они в той или иной степени являются обвертками AJAX. Так, там есть технология RMC, в которой клиент вызывает методы на сервере, как обычные локальные методы. Код серверной части, конечно, при этом, должен разрабатываться с учетом определенных правил. Впрочем, большая часть деталей взаимодействия остается невидимой разработчику и выполняется прокси классами, генерируемыми компилятором. Также возможно использование обычного HTTP и некоторых других подходов.

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

+ Как и все современные AJAX решения GWT поддерживает типовой AJAX подход для реализации закладок и истории браузера.

+ GWT позиционируется как кросс браузерное решение. Конечно, если в браузере чего-то нет, то это работать не будет. В качестве примера можно привести window close listener, который реализован в Firefox и не реализован в Opera (по крайней мере в версиях ниже 11-ой). Вы можете использовать соответствующее API из GWT, однако ваш listener будет вызываться, когда код исполняется в Firefox, и не будет, когда – в Opera. Однако, если возможность выполнить что-то присутствует в обоих браузерах, но для этого должен быть написан разный js код, GWT в теории прячет это различие от разработчика. К сожалению – только в теории. В процессе написания нашего небольшого проекта были отмечены по крайней мере 3 случая, когда GWT код пришлось дорабатывать, чтобы он работал не только в FF, но и в Chrome. Это не связано с особенностями браузера, скорее, это ошибки в реализации GWT.

+ GWT – это компонентное решение, т.е., когда пишется код, на странице размещаются не html тэги, а компоненты или Widget-ы. Компоненты могут соответствовать обычным HTML тэгам (например кнопка – Button) или быть очень сложными (например, текстовый редактор с поддержкой стилей и форматирования – RichTextArea). Имеется огромное количество библиотек компонент для GWT, развиваемое с тем или иным успехом различными группами и даже компаниями. Здесь нужно быть предельно осторожным и выбирать только библиотеки, прошедшие проверку временем и имеющие аргументированные положительные оценки сообщества GWT разработчиков. Можно также самим создавать настраиваемые компоненты, просто наследуя класс Composite. Имеются также библиотеки не для GWT, но которые используют GWT в качестве базиса. Примером одной такой интересной библиотеки может служить Smart GWT Widget Library.

+ Компонентные классы могут наследоваться и эти наследники размещены там, где может быть размещен базовый класс.

+ Многие подходы в разработке здесь похожи на подходы, применяемые в swing. К сожалению, не только положительные. Если следовать классической модели GWT, вам придется “слепить” страницу при помощи java кода, так же, как это делается в Swing. Это приводит к набору (typing) большого объема кода, отсутствию наглядности и трудностям с модификацией HTML разметки. Впрочем, здесь есть не вполне полноценное, но решение (как,  и в Swing), облегчающие жизнь программистов. Более подробно смотри на сайте google – UiBinder template и GWT Designer, а также следующий пункт.

+ Как уже отмечалось, GWT – это, прежде всего, решение для клиента. Поэтому обычно не возникает никаких проблем с комбинированием его с различными template подходами – jsp+jstl, velocity, jsf и др. Просто вставьте тег загрузки скрипта на (например, jsp) страницу и напишите процедуру, обрабатывающую принятую браузером html страницу.

+ Поскольку js исполняется в одной нити (опять вспоминаем Swing), то, программируя в GWT, нет нужды заботиться о синхронизации и других проблемах мультипоточных приложений, по крайней мере в традиционном для java понимании этого термина.

+ GWT имеет доступ к DOM элементам, размещаемым или размещенным на странице, может вызывать функции javascript (из других библиотек или написанные на js для этого проекта), позволяет из js вызывать методы, закодированные на java. Есть встроенные методы генерации низкоуровневых событий мыши и клавиатуры. Т.е. имеется довольно полная интеграция с браузером. Если ее не хватает – можно написать свои js функции и вызывать их из GWT кода или наоборот.

+ GWT плагины для Eclipse и Firefox позволяют запускать приложение в режиме эммуляции (т.н. development mode) и отлаживать клиентский (и, конечно, серверный) код как обычное java приложение с использованием пошагового режима, точек останова, просмотра текущего значения переменных и т.п. Имеются плагины и для других IDE и браузеров (я встречал упоминания про IntelliJ IDEA и Chrome).

+ Разрабатывая приложение на GWT, следует помнить, что, хотя можно использовать несколько html страниц, каждый раз при переходе со страницы на страницу, все внутреннее состояние страницы (переменные, экземпляры классов и т.п.), откуда был переход, будет теряться. Если это не желательно – используйте одну страницу с переключаемыми видимыми участками. Это может существенно увеличить количество загружаемого GWT-js кода.

+ GWT постоянно развивается. Причем, такое ощущение, что разработчики не особенно беспокоятся о поддержке старого API. С выходом каждой новой версии часть API объявляется depricated и вместо него предлагается использовать новое. Зачастую это ключевые классы. Так, при выходе версии 2.1 все классы, обеспечивающие отложенную обработку, были объявлены depricated. Это плохая практика, заставляющая авторов программ проводить постоянный рефакторинг или отказаться от удовольствия использовать новые возможности. Иногда классы не объявляются depricated, но в описании, упоминаются как устаревшие (т.е., возможно, скоро будут depricated), а для тех, которые рекомендуются им на замену, нет полного комплекта документации. Типичный пример – рекомендация об использовании Layout Panels вместо обычных Panels. Для первых нет до сих пор хоть какого-нибудь tutorial.

+ Еще одна проблема – это то, что дополнительные библиотеки переписываются с учетом изменений в базовом API значительно позже выхода этого API. Более того без модификации они могут не работать с новыми объектами совсем.

+ GWT и, тем более, его дополнительные библиотеки с задержкой, иногда значительной,  отражают последние улучшения поддержки браузерами стандартов HTML5, CSS3 и т.п. И чтобы использовать эти новые возможности приходится все равно писать на JS.

+ Зачастую, некоторые вещи (например, drag& drop) GWT реализует существенно более сложным образом, чем они могли бы быть закодированными на JS. Это забирает дополнительное время и силы у разработчиков.

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather