Меня интересует возможность того, что GWT может служить основой для всего моего уровня представления.
Мне было бы интересно узнать, пробовал ли кто-нибудь это успешно - или безуспешно - и мог бы убедить или отговорить меня от попытки.
Меня интересует возможность того, что GWT может служить основой для всего моего уровня представления.
Мне было бы интересно узнать, пробовал ли кто-нибудь это успешно - или безуспешно - и мог бы убедить или отговорить меня от попытки.
Я работал с GWT около года назад. В то время это казалось отличной идеей, но с некоторыми оговорками:
При этом, похоже, с этим определенно стоит поиграть, и мой опыт был давным-давно в годы Интернета, особенно с учетом того, что сейчас он, вероятно, намного более зрелый. Также стоит отметить, что это совсем другой (и освежающий) способ разработки кода GUI по сравнению с большинством фреймворков MVC, и его стоит изучить, хотя бы по одной другой причине.
Я считаю, что если вы создаете высоконагруженный профессиональный сайт с очень требовательными графическими требованиями, GWT, вероятно, не лучший выбор, в остальном все в порядке.
Вы упомянули, что GWT будет обрабатывать презентационный уровень. Вы бы тоже занимались бизнес-уровнем на Java? Если это так, я хотел бы указать вам на IT Mill Toolkit, который делает именно это: это набор инструментов, который использует GWT для рендеринга своих компонентов графического интерфейса пользователя, что позволяет вам делать свои приложения полностью на Java. Я думаю, что термин, который он пытается использовать, звучит как «RIA, управляемая сервером».
У меня был опыт работы с PHP, но инструментарий мне сразу понравился. Но, наверное, будет лучше, если я больше ничего не скажу и позволю вам принимать решения самостоятельно.
Предупреждение: я работаю в IT Mill, хотя это не имеет отношения к моему мнению.
GWT относительно новый. Процесс компиляции имеет тенденцию замедляться по мере роста вашей кодовой базы. Когда мы работали с ним, мы обнаружили много проблем с макетом и рендерингом более сложных виджетов, а эмулятор действовал совершенно иначе, чем реальные серверы. Также у нас были проблемы с i18n для языков с письмом справа налево ...
В общем, у GWT есть (обычные?) Проблемы молодых технологий. Тем не менее, он действительно упрощает некоторые вещи, например, Ajaxifying, как вы его назвали.
Мы сделали это для очень большого проекта, и пока вы знаете его ограничения, сильные и слабые стороны, он отлично работает. Как ни странно, презентация была наименьшей из наших проблем, поскольку мы просто обработали ее, как и любую другую HTML-страницу, с помощью CSS. Проект был запущен и работал безупречно, так что у меня нет претензий.
Ловушки, которые я обнаружил, вы можете найти здесь:
Самые большие подводные камни GWT?
Мы разработали большое приложение HR Portal, в котором весь уровень представления выполнен в GWT. Бэкэнд - Spring. Все работает очень хорошо, и пользовательский интерфейс был очень хорошо воспринят пользователями. Очень важно, что нам легко добавлять новые функции и поддерживать приложение. Я думаю, что было бы намного сложнее сделать что-то сопоставимое и поддерживаемое с использованием библиотек Javascript.
Вам действительно нужна какая-то платформа на стороне клиента, иначе вы ее напишете (как это сделали мы!): Наше приложение построено на Портлеты GWT (бесплатно и с открытым исходным кодом).
Мы используем фрагменты HTML для создания скинов приложения для различных развертываний, а макет каждой «страницы» сохраняется в файле XML.
немного полезной информации об этом в этом веселом видео: http://raibledesigns.com/rd/entry/my_drunk_on_software_interview
GWT сам по себе является библиотекой улучшения пользовательского интерфейса, а не фреймворком. Если вы используете его с Google App Engine, у вас будет базовая структура. (Это другая история, и пока я смотрел на нее, я решил не включать это в нашу архитектуру).
Это отличная библиотека, мы проделали с ней несколько впечатляющих вещей. Однако, поскольку это библиотека, она настолько хороша, насколько позволяет ваша архитектура.
Что касается ANT, то с 64-битным компилятором проблем нет.
‹Java failonerror =" true "fork =" true "classname =" com.google.gwt.dev.Compiler "dir =" $ {dir.GWTCompile} "› ‹- dir.GWTCompile - это каталог, содержащий GWT -› ‹Classpath› путь к классам ‹/classpath› ‹jvmarg value =" - $ {gwt.maxMem} "/› ‹arg value =" @ {gwt.baseModule} "/› ‹arg value =" DEBUG "/› ‹arg value = "-strict" / ›‹/java›
Что касается сгенерированного кода, все это есть на вашей войне, если вы хотите его просмотреть. (Это также открытый исходный код, так что вы можете посмотреть его там.)
Что GWT делает в процессе компиляции: он создает несколько копий JS-библиотек для разных наборов браузеров (одна из причин, по которой компиляция может занять несколько минут), вы можете добавлять / удалять их по мере необходимости. Это уменьшает количество JS-пакета, который необходимо загрузить, и увеличивает скорость, поскольку в нем не должно быть этих неприятных if (EI) this else if (FF) that. Однако, когда вы выполняете локальную отладку (по крайней мере, в eclipse), вам не нужно ждать, что позволяет оставить это для сервера сборки (или когда вам нужно вручную собрать и развернуть (неандертальцы)).
Обратная сторона GWT. Поскольку это клиентская сторона javascript (почти полностью), вы не можете использовать ее для вещей, которые ее не поддерживают или не поддерживают одну из версий. Поэтому для таких вещей, как iPad и iPhone, вы можете столкнуться с некоторыми проблемами, если не используете дополнительные библиотеки, предназначенные для устранения этих пробелов (например, mgwt).