Google Web Toolkit
Google Web Toolkit (GWT , ˈɡwɪt ) — свободный Java-фреймворк, который позволяет веб-разработчикам создавать Ajax-приложения на основе Java. Выпускается под лицензией Apache версии 2.0. GWT делает акцент на повторное использование и кросс‐браузерную совместимость.
История
Версия 1.0 RC 1 (build 1.0.20) выпущена 16 мая 2006 года. Компания Google анонсировала GWT на конференции JavaOne в 2006 году.
- GWT 1.0 — 17 мая2006 года
- GWT 1.1 — 11 августа2006 года
- GWT 1.2 — 16 ноября2006 года
- GWT 1.3 — 5 февраля2007 года
- GWT 1.4 — 28 августа2007 года
- GWT 1.5 — 27 августа2008 года
- GWT 1.6 — 7 апреля2009 года
- GWT 1.7 — 13 июня2009 года
- GWT 1.7.1 — 22 сентября2009 года
- GWT 2.0 — 8 декабря2009 года
- GWT 2.0.1 — 2 февраля2010 года
- GWT 2.0.2 — 12 февраля2010 года
- GWT 2.0.3 — 18 февраля2010 года
- GWT 2.0.4 — 2 июля2010 года
- GWT 2.1.0 — 19 октября2010 года
- GWT 2.1.1 — 16 декабря, 2010 года
- GWT 2.2.0 — 11 февраля, 2011 года
- GWT 2.3.0 — 5 мая, 2011 года
- GWT 2.4.0 — 8 сентября, 2011 года
- GWT 2.5.0 — 27 июня, 2012 года
Разработка
Используя GWT, разработчики могут быстро писать и отлаживать AJAX приложения на языке Java, используя инструментарий отладки Java. Компилятор GWT переведёт код Java приложения в соответствующий браузеру JavaScript и HTML.
Утилита командной строки applicationCreator, поставляемая вместе с GWT, автоматически создает все файлы, необходимые для нового GWT-проекта. Она также позволяет создавать файлы проекта Eclipse.
Существует подключаемый модуль Google Plugin для IDE Eclipse версий 3.3 — 3.7, позволяющий упростить процессы создания GWT-проекта и размещения готовых приложений на сервисе Google App Engine.
Компоненты
Основные компоненты GWT:
Компилятор GWT Java-to-JavaScript Переводит Java код в JavaScript. GWT Hosted Web Browser Позволяет запускать GWT приложения в режиме hosted (приложения запускаются как Java код в JVM без компиляции в JavaScript). JRE emulation library Реализация часто используемых стандартных Java классов на JavaScript. GWT Web UI class library Множество пользовательских интерфейсов и классов для создания виджетов.
Примечания
- ↑Google Web Toolkit Release Archive — Google Web Toolkit — Google Code
См. также
Ссылки
ColdSpring • Fusebox • Mach-II • Model-Glue
Apache (Cocoon • Struts • Velocity • WebWork 2) • AppFuse • Aranea • Eclipse • Facelets • Flexive • FreeMarker • Google Web Toolkit • Grails • Hamlets • ItsNat • JavaServer Faces • Jspx • JBoss Seam • jZeno • Makumba • OpenLaszlo • OpenXava • Reasonable Server Faces (RSF) • Restlet • RichFaces • RIFE • Shale • SmartClient • Spring • Stripes • Tapestry • ThinWire • Vaadin • WebMacro • WebWork • WebObjects • Wicket • ZK
Catalyst • Interchange • Titanium • Maypole • HTML:Mason
Acode • Akelos • BlueShoes • CakePHP • Canvas • CodeIgniter • DIY • Drupal • Fuse • Horde • Kohana • LiveStreet • PHP For Applications • PHPOpenbiz • PRADO • Qcodo • Seagull • Solar • Symfony • W3Core • Yii • Zend • Zoop • Joomla
Camping • Nitro • IOWA • Ramaze • Cerise • Merb • Ruby on Rails • Sinatra • Padrino
Macintosh Toolbox/Carbon • Windows API • Intrinsics • Intuition • Xlib
BOOPSI • Magic User Interface • Zune • ReAction GUI
Cocoa • MacApp • MacZoop • PowerPlant
ASWing • Adobe Flex • Gnash • SWF2EXE Software
Ample SDK • CougarXML • Dojo Toolkit • Echo • ExtJS • GladeXML • Google Web Toolkit • jQuery • Lively Kernel • MooTools • Pyjamas • qooxdoo • Rialto Toolkit • script.aculo.us • XML User Interface • XUL • Yahoo! UI Library
Agar • CEGUI • Component Library for Cross Platform • dlib C++ Library • FLTK • FOX toolkit • OpenGL User Interface Library • GTK+ • IUP • Juce • JX Application Framework • Qt • TnFOX • Visual Component Framework • wxWidgets • YAAF • XForms • XVT • Ultimate++
CAPI • Common Graphics • CLIM • McCLIM • Garnet
Pyjamas • PyQt • PyGTK • PyGUI • wxPython • PySide • Tkinter
LiveStreet
Google Web Toolkit → Google Web Toolkit Intro
Доброго времени суток! Сегодня я начну рассказ о замечательном тулките — GWT.
Google Web Toolkit это средство для создания rich internet application. Их поведение будет очень похоже на десктопные приложения, но средой исполнения будет браузер. Построение пользовательского интерфеса не похоже на обычное для webа и больше похоже на создание десктоп приложения.
В основе GWT лежит компилятор, который переводит java-код в java-script + html + xml в этом и состоит главное преимущество этого тулкита — браузеру не требуются никакие плагины (в отличие от апплетов, javafx-скриптов, flash/flex или silverlight). Так как пишется весь код на чистой java (по желанию конечно можно использовать native java-script код), то он имеет всю мощь огромного набора java библиотек, которые вы можете использовать. Но вот тут встречается первый минус. На клиентской стороне вы можете использовать только некоторыми основными библиотеками (java.lang java.utils etc) другие же приведут к ошибке компиляции. Но на серверной стороне вас никто ничем не ограничивает.
Часть 1 Установка
Чтобы установить можно пойти двумя путями. Первый это скачать последнюю стабильную версию gwt, распаковать ее в нужную вам директорию, и далее создать проект, и приложение встроенной утилитой webAppCreator (ранее было две утилиты projectCreator и applicationCreator, теперь же они объединены в одну). Далее нужно импортировать созданный проект в эклипс и можно начинать работу.
Но есть путь гораздо проще достаточно подключить репозиторий:
в меню eclipse install software и установить нужный плагин. Дальше создаем новый web project и получаем удовольствие. Этот путь на мой взгляд предпочтительнее, потому что версия gwt всегда последняя (если включен autoupdate в eclipse), но по-умолчанию это проект будет использовать Google App Engine, но его легко отключить в свойствах нового проекта.
Чтобы подключить полезную библиотеку готовых виджетов(продуманных, удобных и более красивых 🙂 ) можно использовать библиотеки extjs . Полюбоваться ими можно в демонстрации . Там же можно скачать библиотеку и найти иснтрукцию по установке, это абсолютно банально.
С завтрашнего дня я буду рассматривать ключевые моменты один за дургим. Построение самих интерфейсов процесс банальный и понятный, самое проблематичное и интересное это взаимодействие с серверной частью.
Полезные ссылки:
- Google,
- Google Web Toolkit,
- eclipse
- +3
- sidney3172
- 08 октября 2009, 00:23
Комментарии ( 7 )
Я ведь верно понимаю, что это js, ajax и хитрзадые манипуляции с dom на странице в браузере?
Это кендец. Они кодят окошечки с кнопочками, менюшечками и иконочками. Выглядящие, как полноценные виндовские контролы. Средствами браузера, блин.
Что дальше? Закодим рендерер веб-страниц и скриптовый движок внутри сайтика? Чтобы можно было браузер в браузере сделать, лол?
В НФ-литературе встречается идея о всяких информационных полях. Типа, когда разумная раса накапливала достаточно материи с низким значением энтропии, к ней приходил пибольшой полярный лис. Или там идеи про лимит количества разумных единиц в ограниченном объёме.
Мне очень хочется, чтобы существовал эдакий незримый предел избыточности кода, эдакий предел оверхеда по функциональности. Чтобы всем идиотам само мироздание надавало по башке.
Путь IT-развития человечества вырождается в хер пойми что. Или уже его достиг.
Я всё.
эко ж Вас разразило)
Я ведь верно понимаю, что это js, ajax и хитрзадые манипуляции с dom на странице в браузере?
Да все так, вы верно понимаете.
Не понимаю вашей глобальной нити рассуждения. Зачем же браузер в браузере? Что это такое вообще?=)
Просто попытка все вынести в веб в конечном итоге весь функционал операционной системы. А реализуют теми средствами какие сейчас есть. Ничего плохого в этом я не вижу. К тому же js гораздо лучше и логичнее чем многие популярные сейчас технологии а-ля flash/flex, тот же javaFx.
А если вы или кто-то ещё придумает что-то иное более правильное и логичное все с радостью начнут использовать.
А вообще этот коммент у меня родил ассоциацию, нафиг поезда и самолеты, я вот в НФ-литературе читал про телепорты…
Простите если я что-то не понял)
> К тому же js гораздо лучше и логичнее чем многие популярные сейчас технологии а-ля flash/flex, тот же javaFx.
+100500
> Просто попытка все вынести в веб в конечном итоге весь функционал операционной системы.
Соль в том, что в такого рода системах слишком много слоёв абстракции, вот и всё, что я хотел сказать этой питательной копипастой.
>К тому же js гораздо лучше и логичнее чем многие популярные сейчас технологии а-ля flash/flex, тот же javaFx.
А мне наоборот кажется. На мой взгляд JavaScript + HTML изначально задумывался как добавление интерактивности к веб-данным, но никак не для написания сложных программ.
Конечно, за врямя своего существования люди приспособились и написали замечательные библиотеки. Но вот именно подход GWT мне не очень нравится. Цель как раз отойти от JavaScript и заменить его на более строгий Java. Тот же flash развивается и перенесен почти на все платформы, с# и silverlight замечательная вещь (пока не хватает кросплатформенности, но intel и mono возможно решат это).
А так код всегда виден, java script исполняется дольше, чем тот же .net байт-код, для каждого браузера свой сгенерированый код. Конечно сейчас это как-то работает, но ИМХО тупиковый путь.
Тот же flash развивается и перенесен почти на все платформы, с# и silverlight замечательная вещь (пока не хватает кросплатформенности, но intel и mono возможно решат это).
а что у js какие-то проблемы с кроссплатформенностью?
java script исполняется дольше, чем тот же .net байт-код
вот на эту тему я думаю можно будет поспорить на самом деле. Далеко не факт что .net будет быстрее, к тому же его проблемы с переносимостью (как вы сказали intel и mono можеть быть, когда-нибудь и решат эти проблемы, но не в обозримом будущем), а тот же java байт-код, не отличается скоростью.
а что у js какие-то проблемы с кроссплатформенностью?
Да почему же, теоретически(!) у него хорошая кросплатформенность, требуется лишь наличие браузера. А вот практически все тоже не так прекрасно. Взять хотя бы текущую не полную совместимость браузеров даже на десктопе (хотя дело движется). Те кроме проприетарного момента JS + html не более переносим чем тот же, flash, silverlight или java — всем нужно нечто для исполнения, все можно сделать кроссплатформенным.
как вы сказали intel и mono можеть быть, когда-нибудь и решат эти проблемы, но не в обозримом будущем
Насчет обозримого будущего. То же можно сказать про стандарт html5 скажем, может быть его примут в обозримом будущем. А до этих пор он не более, чем инициатива отдельных компаний и корпораций.
Ну и самое главное. Если кому GWT помогает, то отлично. Но сам подход похоже создан от безысходности. Зачем мне, скажем, писать программу на с++, чтобы она транслировалась в ruby. Когда с++ скомпилированная программа намного быстрее и я все равно пишу на с++. Байт-код виртуальные машины такие как jvm и .net изначально позволяют писать код на удобном языке. Просто Sun как-то перестал заниматься улучшением и развитием встраиваемых апплетов(второй заход javafx) и его от туда вытеснил тот же flash, ну а microsoft просто многие не любят, а ведь подход правильный!
Google закрывает Инструменты переводчика
Google недавно разослал извещение о том, что 4 декабря закрывает сервис Инструменты переводчика или как его еще называют Google Translator Toolkit.
Недавно мы сообщали Вам, что 4 декабря 2019 мы прощаемся с Инструментами переводчика Google. Вы получили последнее напоминание, поскольку сервис прекратит работу менее чем за 2 недели. Ниже мы описали, как Вы можете загрузить свои данные.
Вы можете загрузить свои данные из Инструментов переводчика до 4 декабря 2019. Некоторое время после прекращения работы сервиса данные можно будет загрузить с Google Takeout.
Таким образом Google Translator Toolkit вслед за Google Reader, Google+ и другими добавляется к обширному списку закрытых сервисов Google.
Хоть в письме и не сообщается отдельно, но вряд ли это как-то повлияет на работу Google Translator.
Google Translator Toolkit — это онлайн-инструмент для автоматизированного перевода. С его помощью переводчики могут использовать общие переводы, глоссарии и собственную память переводов. Они могут загружать и переводить документы Microsoft Word, OpenDocument, RTF, HTML, текст и статьи из Википедии.
- Google API
- Облачные сервисы
- IT-компании
Google Web Toolkit и клиентская оптимизация
Чем медленнее загружается и работает web-приложение, тем меньше пользователей захотят им воспользоваться. Google понимает это как никто другой, поэтому в созданном ими Web Toolkit особое внимание уделено скорости работы получаемых с его помощью web-приложений.
Статья рассказывает о том, какие приемы клиентской оптимизации используются в GWT.
Отдельная версия приложения для каждого браузера
У каждого браузера есть свои особенности, что известным образом усложняет жизнь разработчику. Так, например, чтобы получить объект XMLHttpRequest (необходимый для выполнения асинхронных запросов к серверу из JavaScript) в IE6, проходится использовать ActiveXObject:
var xhr = new window. ActiveXObject ( «Microsoft.XMLHTTP» ) ;
Все остальные (отличные от IE) браузеры предоставляют встроенную поддержку объекта XMLHttpRequest:
var xhr = new window. XMLHttpRequest ( ) ;
Обычно (так устроено большинство JavaScript-библиотек) в подобных ситуациях в web-приложение включают все браузеро-зависимые реализации, а в каждом конкретном браузере используют только одну из них, выбирая её по ходу выполнения, то есть после того как будут загружены и разобраны в том числе и не нужные реализации.
В Google Web Toolkit применяют отличное (во всех смыслах) решение: для каждого браузера собирается отдельная версия web-приложения, называемая пермутацией. Каждая пермутация содержит всё, что необходимо для работы только в одном браузере, поэтому, например, «огненному лису» никогда не придется загружать и разбирать JavaScript или CSS специфичные для IE.
Оптимизация, минимизация и обфускация
Чтобы ускорить загрузку web-приложения, JavaScript и CSS обычно минимизируют, например, с помощью YUI Compressor, который за счет удаления пробельных символов и прочих необязательных конструкций, а также в результате обфускации, значительно сокращает их размер.
Google Web Toolkit также проводит минимизацию и обфускацию, но на вход минимизатора поступает JavaScript, не написанный человеком, а полученный в результате работы Java-в-JavaScript компилятора. Компилятор безопасно удаляет неиспользуемый код, разворачивает методы, оптимизирует полиморфные отношения, вычисляет константные выражения и делает многое другое, в результате чего получается оптимизированный (по размеру и по скорости работы) JavaScript.
Небольшой (примитивный) пример:
public static double getArea ( double radius ) <
return Math . PI * radius * radius ;
>
public static double getCircumference ( double radius ) <
return Math . PI * radius * 2 ;
>
double a = CircleMath. getArea ( 7.5 ) ;
double c = CircleMath. getCircumference ( radius ) ;
Во время компиляции CircleMath будет удален, его статические методы будут заменены inline-вставками, а математические выражения оптимизированы. В результате получится такой JavaScript:
var a = 176.714586788 , c = 6.283185308 * radius ;
Оптимизация для лучшего сжатия Gzip
Все современные браузеры поддерживают сжатие, которое (при правильной настройке web-сервера) позволяет значительно уменьшить размер передаваемых данных. Особенно хорошо сжимаются HTML, CSS и JavaScript, уменьшаясь в среднем на 75%.
Такие во многом зависящие от самих данных результаты показались инженерам Google неудовлетворительными, поэтому они модифицировали обфускатор, входящий в состав Google Web Toolkit так, чтобы получающийся на выходе обфусцированный код всегда сжимался Gzip как можно сильнее.
Чтобы представить, как это работает, сожмем с помощью GNU Gzip две строки:
a b c b a c a b c a b c b a c a b c
a a a a a a b b b b b b c c c c c c
Можно заметить, что обе строки состоят из одинакового числа одинаковых символов, а отличаются только порядком некоторых из них, при этом после сжатия первая строка не уменьшится ни на байт, тогда как вторая станет на 3 байта короче. Аналогичным образом, если поменять порядок объявления функций в JavaScript, так чтобы повторяющийся код, находился в рамках одного «скользящего окна», скрипт будет сжиматься сильнее, чем при случайном порядке объявления функций.
CSS sprites и встроенные изображения (data:URL)
CSS спрайты и встроенные изображения помогают уменьшить число обращений к серверу, необходимых для загрузки интерфейсной графики web-приложения. В большинстве случаев можно было бы ограничиться одними встроенными изображениями, но так как они не поддерживаются некоторыми все ещё широко-используемыми версиями IE, приходится применять обе методики.
Для построения интерфейса пользователя Google Web Toolkit позволяет использовать привычные технологии: HTML и CSS, несколько расширенный синтаксис которых помогает без каких-либо дополнительных усилий и знаний решить проблему обеспечения кросс-браузерной оптимизации загрузки изображений:
@sprite .image1 <
gwt-image : «image1» ;
/* . CSS properties . */
>
@sprite .image2 <
gwt-image : «image2» ;
/* . CSS properties . */
>
Во время сборки web-приложения, включающего такой UI-шаблон, 1.png и 2.png будут объединены в одно изображение, которое будет использовано в пермутациях для IE6 и IE7 посредством CSS Sprites. Во все остальные пермутации исходные изображения будут встроены в виде data:URL. В обоих случаях все необходимые свойства будут добавлены в CSS-классы image1 и image2 автоматически.
Разделение приложения на модули
Механизм пермутаций Google Web Toolkit, позволяет современным браузерам загрузить HTML, Javascript, CSS и изображения — всё компоненты web-приложения — в виде единого файла за одно обращение к серверу.
С ростом функциональности web-приложения неизбежно растет размер пермутаций, а соответственно увеличивается время необходимое для загрузки каждой из них. Может наступить момент, когда «холодный старт» (кэш браузера пуст), даже с учетом всех возможных оптимизаций, начнет занимать неприемлемо большое время.
На этот случай Google Web Toolkit предоставляет возможность разбить web-приложение на несколько отдельно-загружаемых модулей. Таким образом основные функции большого приложения можно сделать доступными для пользователя сразу после загрузки небольшого стартового модуля, а остальные, обеспечивающие дополнительную функциональность модули подгружать по мере надобности. Модули создаются и подгружаются автоматически, от разработчика требуется лишь указать точки разделения.
Используя модули, разработчики Google Wave смогли довести среднее время загрузки своего детища до нескольких секунд, хотя полный размер этого «монстра» равен примерно 3 Мбайтам.
- google web toolkit
- gwt
- клиентская оптимизация