Тому, у кого уже есть обширный опыт работы с JSP/JEE и HTML/Javascript, на понимание GWT потребуется всего полдня. Но на освоение у вас уйдет два месяца.
Вот рекомендация по сочетанию технологий с GWT, которая, как я считаю, сделает ваши приложения корпоративного уровня успешными. Я думаю, вам следует использовать GWT из-за его отладки. Но отладка имеет свою цену. Для отладки GWT требуется как минимум четырехъядерный компьютер с 8 ГБ памяти. Если вы считаете, что это не так, возможно, это потому, что вы нашли способ сделать свой пользовательский интерфейс GWT маленьким и простым.
Eclipse зависает при отладке приложения GWT
RequiresResize, ProvidesResize и макеты
Первое, что вам нужно освоить в GWT, — это простая концепция макетов, которые диктуются интерфейсами RequiresResize, ProvidesResize. Вам необходимо убедиться, что цепочка RequiresResize/ProvidesResize от RootLayoutPanel до виджетов с изменяемым размером должна быть непрерывной. И вам нужно освоить архитектуру потока RequiresResize/ProvidesResize в вашем пользовательском интерфейсе. В противном случае при изменении размера браузера вы увидите один или два странных висящих фрукта, размер которых не изменится.
Я думаю, что любой ценой следует избегать написания запланированных изменений размера для каждого виджета, а не в зависимости от Google RequiresResize/ProvidesResize. В противном случае не забудьте отменить изменение размера за несколько итераций. Слишком много проб/ошибок, чтобы усовершенствовать изменение размера.
Асинхронный Асинхронный Асинхронный
Следующая концепция, которую вам нужно принять... Я не сказал «вам нужно учиться», но «вам нужно принять» — это асинхронное поведение Javascript и, следовательно, GWT Java. Неважно, использовали вы GWT или нет. Вы должны привыкнуть к инверсии управления, предоставленного вызываемому объекту, чтобы контролировать успешный ответ вызывающего объекта.
Вы не можете писать
List<Persons> persons = server.getData(personId);
Вы должны уступить делать
server.getData(personId, new Callback<Persons>(){
@override public void onSuccess(Person person){ ..... }
@override public void onFailure(Exception ex){ ..... }
});
Вы не можете писать
boolean doOrNot = ConfirmDialogBox();
Вы должны написать
ConfirmDialogBox(new CloseHandler(){
public void onAccept(Person person){ ...}
public void onCancel(){ ... }
});
GWT — это Java, но не Java
Меня забавляет постоянное существование людей, которые продолжают пытаться использовать банки байт-кода apache для компиляции с клиентом GWT, клиент GWT - это Javascript, написанный на Java.
Двоичные данные и GWT
Визуальный клиент GWT
Лучшее сочетание, которое я нахожу, это GWT 2.4.0 с Sencha gxt 2.2.5.
Я избегаю использования проекта GXT-Uibinder, поскольку считаю, что он накладывает неудобные ограничения на другие комбинации сторонних GWT-фреймворков. Особенно те фреймворки, которые сильно зависят от генератора GWT.create(). GXT-Uibinder — это проект за пределами Sencha.
GXT 2.2 и ниже требует, чтобы я написал обертки, чтобы сделать его пригодным для использования с uibinder, из-за моего отказа использовать неуклюжий проект GXT-uibinder. Обертки нужны из-за одного глупого перекоса. Любой класс, используемый в качестве родительского узла виджета в uibinder, должен реализовывать GWT HasWidgets, что требует реализации метода, возвращающего iterator<Widget>. К сожалению, GXT 2.2 уже реализует метод iterator(), который возвращает неверный обобщенный итератор.
GXT 3 решает эту проблему. Я думаю, что GXT 3 включает в себя GXT-uibinder, но вам не обязательно его использовать. Вам не нужно писать много обёрток с GXT 3 (без использования GXT-uibinder), чтобы использовать его с uibinder. Но я считаю, что GXT 3 все еще имеет некоторые причудливые ошибки, и попытка решить эти причуды просто не стоит моего времени. Поэтому я придерживаюсь GXT 2.2.5, пока GXT 3 не стабилизируется.
Я основал проект кода Google для упаковки SmartGWT (uibinding-smartgwt). SmartGWT — очень эгоистичный фреймворк. Мои усилия часто заканчиваются катастрофой, если я пытаюсь смешать его с ванилью GWT. Это связано с некоторой Z-индексацией между виджетами SmartClient и GWT.
Если вы решите использовать SmartGWT из-за проблем с лицензированием, вы должны убедиться, что используете только SmartGWT, а не с каким-либо другим поставщиком виджетов. Даже не ваниль GWT. И вам, скорее всего, понадобится мой проект uibinding-smartgwt. Я пытаюсь улучшить его, чтобы использовать некоторые новые функции uibinder и переопределить невизуальные элементы, чтобы они не были виджетами, но мое текущее использование GXT просто слишком сложно, и одновременная мысль о двух фреймворках смущает меня. Потому что они ведут себя по-разному.
В то время как GXT 3, похоже, полностью соответствует GWT, SmartGWT не продемонстрировал никаких усилий для этого. Полное согласование стороннего поставщика виджетов с GWT, чтобы он плавно реализовывал интерфейсы GWT, абсолютно необходимо, чтобы не тратить много времени на написание кладжей за кладжами для решения некоторых незначительных визуальных проблем. Да, особенно архитектура ProvidesResize/RequiresResize.
Никогда не используйте инкубацию GWT. Попробуйте их, а затем попытайтесь сделать ваш проект удобным для обслуживания, устойчивым и расширяемым. Давай даже не пойдем туда.
Взаимодействие между клиентом и сервером
Не используйте GWT-RPC. НЕ НАДО. За исключением удобства изучения GWT.
RPC хорош для простых приложений, чью роль вы не собираетесь расширять за пределы демо-стадии и едва используемой стадии. Программисты, которые не пишут распределенные/растянутые приложения корпоративного уровня, вероятно, не согласятся со мной.
Модульное тестирование очень полезно при разработке вашего приложения. Сначала забудьте обо всех этих фреймворках модульного тестирования. Просто иметь возможность написать простую процедуру для тестирования каждой маленькой функции, не затрагивая огромную гигантскую картину приложения, очень важно. Я просто хочу проверить этот цикл верблюдизации, например, чтобы он работал. GWT-RPC крайне неудобен для проведения формального/неформального модульного тестирования.
Меня очень привлекает использование JAX-RS REST-RPC через RestGWT на стороне клиента GWT и RestEasy на стороне сервера. Я использую JAX-B в сочетании с реализацией RestEasy обработки Jackson JSON. Вместо Resteasy вы можете попробовать использовать Jersey.
Таким образом, я мог бы использовать клиент FireFox REST для тестирования сервера независимо от GWT. Фактически, после запуска вашего проекта с использованием GWT на стороне клиента вы можете расширить свое приложение, чтобы использовать клиентов без GWT, таких как JQuery, в качестве клиентов для служб REST.
REST также упрощает написание прокси-серверов/туннелирующих серверов, что позволяет обойти ограничения безопасности браузеров SLD-SO-P («домен 2-го уровня, тот же источник»). Принимая во внимание, что формат данных GWT-RPC преднамеренно не поддается расшифровке и нестабилен (я не понимаю менталитета инженера Google, стоящего за тем, как это повышает безопасность, поскольку вы все еще можете видеть биты и фрагменты читаемого человеком текста), я не пытался писать прокси для туннелирования сервисов GWT-RPC. Я не знаю, насколько это жизнеспособно.
http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.
Кстати, script-include для преодоления sld-sop - очень плохая идея. Даже не думай об этом.
Постоянство
Hibernate JPA для не-GAE. Eclipselink JPA для GAE с Google DataNucleus JPA для GAE с хранилищем данных Google.
Сначала я увлекся идеей JDO. Я так старался, а JDO продолжает давать мне конфликты. Я сдался. Сначала казалось, что Google изо всех сил пытается убедить нас, что JDO превосходит JPA. Правда это или нет, но до сих пор мне не удалось приобрести навыки использования персистентности JDO. А поскольку мне приходится программировать и для не-GAE, я не хочу засорять свой разум сложностью JDO.
Причина, по которой я упомянул об этом, заключается в том, что я склонен использовать один и тот же JPA POJO с JAX-RS POJO. Это означает, что я обнаружил, что аннотации JPA, JAX-RS, JAXB и Jackson смешиваются в один и тот же POJO-DTO без конфликтов. У меня часто есть один набор POJO (за некоторыми исключениями), совместно используемый клиентом GWT, сервером JAX_RS и сохраняемостью JPA. Для этого у вас должно быть одно ограничение — все DTO должны быть GWT-сериализуемыми. Не только сериализуемый. По возможности избегайте написания конвертеров dto. Пустая трата времени на три разных набора POJO-DTO, а затем на конвертеры между ними.
Самый ценный игрок
Я считаю, что MVP4G — очень простая в управлении структура MVP. Следующее обсуждение демонстрирует, как я использую MVP4G:
https://groups.google.com/forum/?fromgroups#!searchin/mvp4g/blessedgeek/mvp4g/T6r7egk-3Kk/Jz-dTqZDeMIJ
MVP — очень полезный паттерн. Потому что это помогает мне разделять «проблемы». Когда вы можете разделять проблемы, вы можете тестировать и решать проблемы по отдельности. Это также поможет вам улучшить/расширить ваш проект с минимальным вмешательством/запутанностью, насколько это возможно, со стороны других проблем/модулей вашего лабиринта приложений.
MVP4G также упрощает модульное тестирование, потому что вы можете просто имитировать представление или презентатора или использовать упрощенную шину событий/машину состояний для отладки только тех частей, которые вам нужно отлаживать. И из-за его модульности вы можете легко избежать загрязнения ваших нетестовых классов, чтобы вы могли удалить свои тестовые исходные деревья, не нарушая свои рабочие классы. IOW, вам не нужно изменять свои нетестовые классы, чтобы протестировать их.
person
Blessed Geek
schedule
10.07.2012
