Comments 31
библиотеку gwt-servlet.jar лучше не копировать в WEB-INF/lib, а добавить её в конфигурацию Artifacts. только вчера с такой проблемой столкнулся
и спасибо за видеоурок. думаю, многим он будем полезен.
и спасибо за видеоурок. думаю, многим он будем полезен.
Не тема этого топика, но все же… Не будет ли у вас идей как делать интерфейс на основе плагинов через нечто типа OSGI? Да, это противоречит идеологии GWT, но было бы крайне удобно.
попробуйте Spring DM for OSGi, Spring почти прекрасно интегрируется и в GAE и в GWT. там прозрачная реализация, может быть подкинет вам идей.
хороший видеоурок для начинающих
IDEA рассматривалась которая IDEA Community Edition? Или платная? Мне кажется для GWT самое оптимальная среда это Eclipse c родным плагином от Google.
к сожалению, Community Edition не поддерживает GWT, как и многое другое.
плагин для Eclipse от Google прекрасен, но в Eclipse столько мельких и не очень недоработок, что я после очередной попытки его использовать, через полчаса сдаюсь и возвращаюсь в IntellijIdea.
плагин для Eclipse от Google прекрасен, но в Eclipse столько мельких и не очень недоработок, что я после очередной попытки его использовать, через полчаса сдаюсь и возвращаюсь в IntellijIdea.
у меня точь в точь, тоже самое)
А триал есть у IDEA? Недавно перешел на ихний phpStorm с Zend Studio (форк Eclipse) — доволен блин как слон, производительностью, некоторых фишек правда не достает, но отсутствие лагов и глюков в уже реализованном доставляет.
есть, 30 дней
есть Ultimate Edition с 30 дневным триальным ограничением, есть бесплатная Community Edition, с рядом ограничений (вот сравнение). те, кому нужна полная версия, но они по каким-либо причинам они не могут заплатить, обычно используют EAP, предрелизную сборку, обычно очень стабильную, там тоже ограничение на использование в 30 дней, но не реже чем раз в 30 дней выходит новая сборка.
завидую вашему терпению — меня обычно минут на 10 хватает всего
Спасибо прям то что было нужно, обязательно посмотрю в ближайшие дни.
Не должно web-приложение создаваться с таким огромным количеством костылей. Применение GWT допустимо, если вы, так же как и google, хотите иметь единую платформу, на базе которой планируете строить и объединять большое число web-сервисов. Лишь в этом случае плюсы GWT перевешивают его минусы. Во всех остальных случаях, я бы порекомендовал отказаться от его использования.
очень неубедительно. о каких костылях вы говорите? в итоге вы получаете кроссбраузерный javascript, да, пусть тяжелый, но очень функциональный и весьма расширяемый в любую сторону.
конечно же, в сайте, где хватает 3 статичных страничек, он бессмысленен. в других же случаях он вполне себе в списке рекомендуемых к рассмотрению кандидатов.
конечно же, в сайте, где хватает 3 статичных страничек, он бессмысленен. в других же случаях он вполне себе в списке рекомендуемых к рассмотрению кандидатов.
>> очень неубедительно. о каких костылях вы говорите?
1) Ужасная тестируемость, профилируемость, спагетти-код из вызовов singleton-ов
2) Длительная перекомпиляция кода (бесконечные Compiling permutation… даже если отключить всю«кросбраузерность» в dev-mode)
3) периодические проблемы с сериализацией из-за рассинхронизации кода на клиенте и сервере (спасает только clean)
4) Что бы отвязать DAO-код сервера от клиента, приходится создавать промежуточный слой из TO (Тransfer Objects)
5) Проблемы при дебаге (может случайно повиснуть, может сыпануть левыми исключениями и т.д.)
6) java.util.Date и часовые пояса
7) Раз сделали компиляцию java 2 javascript, то могли бы и java 2 css приделать
8) Общая тормознутость толстого javascript-клиента (дружно вспомнили google wave, google buzz)
>>в итоге вы получаете кроссбраузерный javascript, да, пусть тяжелый, но очень функциональный и весьма расширяемый в любую сторону.
конечно же, в сайте, где хватает 3 статичных страничек, он бессмысленен.
это никак не противоречит тому, что я написал в самом вначале
1) Ужасная тестируемость, профилируемость, спагетти-код из вызовов singleton-ов
2) Длительная перекомпиляция кода (бесконечные Compiling permutation… даже если отключить всю«кросбраузерность» в dev-mode)
3) периодические проблемы с сериализацией из-за рассинхронизации кода на клиенте и сервере (спасает только clean)
4) Что бы отвязать DAO-код сервера от клиента, приходится создавать промежуточный слой из TO (Тransfer Objects)
5) Проблемы при дебаге (может случайно повиснуть, может сыпануть левыми исключениями и т.д.)
6) java.util.Date и часовые пояса
7) Раз сделали компиляцию java 2 javascript, то могли бы и java 2 css приделать
8) Общая тормознутость толстого javascript-клиента (дружно вспомнили google wave, google buzz)
>>в итоге вы получаете кроссбраузерный javascript, да, пусть тяжелый, но очень функциональный и весьма расширяемый в любую сторону.
конечно же, в сайте, где хватает 3 статичных страничек, он бессмысленен.
это никак не противоречит тому, что я написал в самом вначале
1. отличная тестируемость: JUnit, GWTTestCases, Selenium, профилируемость: Firebug, Compile Report, SpeedTracer, спагетти-код может и присутствует, но только в уже откомпилленом варианте, который никто поддерживать в здравом уже не будет, на что тогда вообще создавать проект в GWT;
2. длительная, да. минус конечно, но вполне терпимый;
3. это руки;
4. кхм, это вы не видели как в других фреймворках это делается. если вообще возможно;
5. все могут. я, честно сказать, не сталкивался, но вполне допускаю. но это рабочие моменты и они к вопросу «использовать или нет» не относятся;
6. (:
7. это уж слишком, как по мне. да и с дизайнерами проще разговаривать. впрочем, это фичареквест больше чем недостаток. а что-то компилирует?
8. это из серии «потому что», вот у Seesmic не очень то и подтормаживает.
я, признаться честно, GWT изучаю пару месяцев и у меня есть о чем сказать в негативном ключе, но вы уж очень предвзяты. вполне допускаю, что это не идеальный фреймворк, но уж точно один из тех, на которые стоит взглянуть. а учитываю хорошую интеграцию в GAE, а значит и неплохой бесплатный хостинг + привязка к домену, так и вообще прекрасный вариант.
2. длительная, да. минус конечно, но вполне терпимый;
3. это руки;
4. кхм, это вы не видели как в других фреймворках это делается. если вообще возможно;
5. все могут. я, честно сказать, не сталкивался, но вполне допускаю. но это рабочие моменты и они к вопросу «использовать или нет» не относятся;
6. (:
7. это уж слишком, как по мне. да и с дизайнерами проще разговаривать. впрочем, это фичареквест больше чем недостаток. а что-то компилирует?
8. это из серии «потому что», вот у Seesmic не очень то и подтормаживает.
я, признаться честно, GWT изучаю пару месяцев и у меня есть о чем сказать в негативном ключе, но вы уж очень предвзяты. вполне допускаю, что это не идеальный фреймворк, но уж точно один из тех, на которые стоит взглянуть. а учитываю хорошую интеграцию в GAE, а значит и неплохой бесплатный хостинг + привязка к домену, так и вообще прекрасный вариант.
> 1. отличная тестируемость: JUnit, GWTTestCases, Selenium, профилируемость: Firebug, Compile Report, SpeedTracer
Из всего перечисленного какое-то отношение к gwt имеют только GWTTestCases и Compile Report. Все остальное обычный набор web-разработчика.
Из всего перечисленного какое-то отношение к gwt имеют только GWTTestCases и Compile Report. Все остальное обычный набор web-разработчика.
и? мы же хотим тестировать наше веб приложение? или нет? а вы говорите об «ужасной тестируемости».
а для какие языки \ фреймворки подходят по вашему списку? может я чего не знаю просто.
а для какие языки \ фреймворки подходят по вашему списку? может я чего не знаю просто.
Особенности/ограничения GWT связывают Java/Javascript/Web-разработчиков по рукам и ногам, лишая их возможности нормального использования своих любимых библиотек и инструментов. Полноценное тестирование с помощью GWTTestCase по сложности и неочевидности трюков и хаков запросто переплюнет тестируемый код. Прикрутить Selenium к такой горе асинхронного жаваскрипта тоже не простая задача, решаемая конечно — но и не без дополнительных ограничений.
Архитектура GWT заточена под написание небольших виджетов, а ля гуглмапс. Их написание/интеграцию GWT действительно сильно упрощает. Когда же пишется большое приложение, то как не верти — а все равно выходит нагромождение из анти-паттернов и велосипедов.
Я с gwt сталкиваюсь в работе периодически на протяжении последних 2 лет ещё со времен версии 1.4. В пяти случаях из ста его выбор может стать действительно лучшим техническим решением. Но далеко не всегда нужны свистелки, недокросбраузерность, интеграция в GAE(с тамим числом ограничений) и хостинг непонятно где. Для меня gwt по прежнему расшифровывается как google widget toolkit. И лично я подожду ещё годик другой, пока пока он не станет полноценным web toolkit-ом
Архитектура GWT заточена под написание небольших виджетов, а ля гуглмапс. Их написание/интеграцию GWT действительно сильно упрощает. Когда же пишется большое приложение, то как не верти — а все равно выходит нагромождение из анти-паттернов и велосипедов.
Я с gwt сталкиваюсь в работе периодически на протяжении последних 2 лет ещё со времен версии 1.4. В пяти случаях из ста его выбор может стать действительно лучшим техническим решением. Но далеко не всегда нужны свистелки, недокросбраузерность, интеграция в GAE(с тамим числом ограничений) и хостинг непонятно где. Для меня gwt по прежнему расшифровывается как google widget toolkit. И лично я подожду ещё годик другой, пока пока он не станет полноценным web toolkit-ом
Мы писали наш проект (веб-дванольный) без GWT (на tapestry + «набор любимых библиотек»), и он рухнул под собственным весом при необходимости добавить очередную фичу. GWT с версии 1.3 еще, помог нам щас расти и расти, количество фич просто безумно, код весь статически типизирован и РАБОТАЕТ.
Мы с радостью избавились от наших «любимых библиотек и инструментов», которые просто напросто костыли, и теперь девелопим и отлаживаем в IDEA/Eclipse, а с GWT 2.0 делаем это еще и на любом бровзере.
Приложение огромно, вместе с серверсайдом 1 миллион строк, из них 400К клиентский код на GWT. И ничо 8-)
В версии 2.0 добавили подкачку кода, чтобы ускорить первоначальную загрузку (отложить на потом загрузку редких диалогов итд), так что мы теперь вроде как расслабляемся.
Мы с радостью избавились от наших «любимых библиотек и инструментов», которые просто напросто костыли, и теперь девелопим и отлаживаем в IDEA/Eclipse, а с GWT 2.0 делаем это еще и на любом бровзере.
Приложение огромно, вместе с серверсайдом 1 миллион строк, из них 400К клиентский код на GWT. И ничо 8-)
В версии 2.0 добавили подкачку кода, чтобы ускорить первоначальную загрузку (отложить на потом загрузку редких диалогов итд), так что мы теперь вроде как расслабляемся.
Плюсы:
1. Если много модулей используют одни и те же классы, DAO-объекты, и т.д., то можно вынести всё в отдельный модуль (например, модуль только с сериализованными объектами).
2. Моментальное обновление (Hosted Mode)
Из недостатков, с которыми я столкнулся в ГВТ при разработке seemap.ru:
1. Очень длительная компиляция. Если модулей много, то времени это займёт не мало.
2. Если необходимо внести небольшие изменения, компилировать приходится по новой.
3. Нет поддержки JPA аннотаций -> трудности с DAO
Kaluchi, всё что вы написали, можно сказать и про другие фреймворки, самое главное — руки ;)
1. Если много модулей используют одни и те же классы, DAO-объекты, и т.д., то можно вынести всё в отдельный модуль (например, модуль только с сериализованными объектами).
2. Моментальное обновление (Hosted Mode)
Из недостатков, с которыми я столкнулся в ГВТ при разработке seemap.ru:
1. Очень длительная компиляция. Если модулей много, то времени это займёт не мало.
2. Если необходимо внести небольшие изменения, компилировать приходится по новой.
3. Нет поддержки JPA аннотаций -> трудности с DAO
Kaluchi, всё что вы написали, можно сказать и про другие фреймворки, самое главное — руки ;)
Залил бы видео куданить на Vimeo к примеру.
Подскажите, вот у вас на скринкасте в качестве шрифта достаточно размазанный (не в обиду будет сказано) Courier. А реально в Idea использовать Consolas с ClearType-оптимизацией?
Sign up to leave a comment.
Видеоурок — Java + Intellij IDEA 9 + GWT 2.0 + Apache Tomcat