IceFaces делает тяжеленный код на стороне клиента + на каждый чих пользователя обращается на сервер.
Т.е. поведение самого интерфейса правильней реализовывать полностью на стороне клиента, а с IceFaces это не так.
Кода было сгенерировано 6.1 кб. Это, пожалуй не так уж мало, и с вашего позволения, я не буду постить его сюда.
Если есть желание, могу отправить мылом.
Нет, тут большая часть кода работает на клиенте именно так, как это написано в коде.
Google переписали часть jre, и его ограниченная часть практически портирована в js. Конечно, за один раз подключается не все сразу!
а просветите, пожалуйста, что у ext'а сейчас с лицензией?
раньше, кажется, была lgpl+commercial, а потом они перешли на «плохой» gpl+commercial, после чего популярности у них поубавилось.
Я так понимаю, имелся ввиду extjs. Лицензия extjs — GPL, это правда.
Я думаю, это не имеет значения в случае в js-кодом, т.к. он все равно полностью попадает на клиент, Вы не сможете его скрыть.
При некоторых усилиях вполне возможно представить любое ajax-приложение как комплекс двух частей — клиентской и серверной :)
>При некоторых усилиях вполне возможно представить любое ajax-приложение как комплекс двух частей — клиентской и серверной :)
боюсь, что не получится, иначе б они и не переходили на gpl: extjs.com/products/license.php
Эх… Ext-Js конечно красивый, но конкретно GWT-Ext — помирающее глюкало.
Шаг в сторону — ошибка где-то в недрах JavaScript без какой-либо диагностики. То есть совсем никак невозможно понять, что случилось и как это исправить. Можно только методом тыка обтачивать примеры.
JavaDoc к GWT-Ext написать видимо должен Пушкин.
Исходный автор уже давно срулил писать SmartGWT. А те что остались вместо него, на мои письма гордо молчат.
Потратил месяц на написание поддержки для GWT-Ext в нашем WYSIWYG GUI builder-е для GWT.
Жалею. :-(
Модуль gwt в IntelliJ Idea позволяет настраивать выходной js-код — obfuscated, pretty, detailed. Там это делается с помощью UI, хотя можно просто прописать флаг "-style" для GWT-компилятора. Затем можно запустить скомпиленный war-файла в контейнере сервлетов — и вот вам классическая отладка в firebug. Или еще проще — кнопка compile/browse во встроенном отладчике gwt позволяет тем же FF открывать страницы при отладке.
Про компиляцию я в курсе, GWT Designer в Eclipse тоже это умеет. ;-)
Но все это не делает GWT-Ext лучше, оно по-прежнему глюкало.
И вообще, сначала рекламировать Java вместо JavaScript, а потом оказывается, что таки нужно в JavaScript погружаться. Не-е-е, такие библотеки нам не нужны.
Собственно GWT-Ext сам можно и в Eclipse отлаживать, в hosted mode как Java приложение. Только там в 90% случаев — нырок в JavaScript и переныривание в Ext-Js. А сам Ext-Js есть уже в виде debug, так что все равно, как компилировать GWT код. ;-)
Все правильно — при использовании чистой GWT — ковыряться в JavaScript не нужно.
Но GWT-Ext — это обертка вокруг ExtJs, и решать ошибки можно только путем ковыряния в JavaScript.
Чтобы не быть голословным:
1. попробуй создать CycleButton без item'ов.
2. попробуй создать GridPanel без колонок и данных.
3. аналогично любая ChartPanel.
4. бросить GWT-Ext Button на layout.
Ошибки обычно офигительно полезные…
com.google.gwt.core.client.JavaScriptException: (TypeError): Объект не поддерживает это свойство или метод
number: -2146827850
Все, полный конец обеда. Из Java исходников ничего не видно.
Но это не делает GWT-Ext лучше.
Проблемы, которые требуют гугления и спрашивания в форуме всегда будут.
Но до определенного уровня качества пользоваться библиотекой нельзя. В это входит в том числе документация и нормальная диагностика ошибок. Согласись, падать с дикими ошибками в Javascript — это не дело.
Java вместо javascript (gwt+netbeans)