Читается как «зэк»? :)

имеет безопасную архитектуру: вся логика приложений выполняется на стороне сервера

Как одно с другим связано-то?

Это не для сайтов, а для http://ru.wikipedia.org/wiki/RIA

Если логика на стороне клиента, злой кулхацкер может подменять её присылая поддельные запросы.

А если логика на сервере посылать поддельные запросы принципиально невозможно?

Если логика на стороне клиента, злой кулхацкер может подменять её присылая поддельные запросы.

Если приложение всегда доверяет пользовательским данным, это проблемы разработчика и приложения. Казалось бы, при чем здесь фреймворк?

Отличная новость. Как-раз хотел попробовать что-нибудь написать на Java. Удивительно, что только сейчас услышал про этот фреймворк

Думаю, ежели есть хоть какая-нибудь защита, допустим csrf, то все будет пучком =)

а что на клиентской стороне??? хз, может попробую :)

Ой предчую срач.... :(

GWT куда как интереснее - выполнение всей логике на сервере замедляет работу клиента (передача по сети - самая медленная операция) + повышает нагрузку на сервер. А в классе «server-side» библиотек гораздо интереснее Eclipse RAP.

Ява? Не годно!

выполнение всей логике на сервере замедляет работу клиента

4.2 когда интерфейс перестанет быть на html тогда и будет замедлять, а пока тормозит бравзер

4.2 когда интерфейс перестанет быть на html

4.2 - JavaScript даже с html уже давно достаточно быстрый. И разгрузка сервера задачами, с которыми справляется клиент позволяет быстрее выполнять те запросы, которые клиент выполнить не может.

Это вы рассказываете человеку который занимается оптимизацией этой самой js-пронографии?

4.2 когда интерфейс перестанет быть на html тогда и будет замедлять

Это вы расказываете человеку, у которого генерация представления _целиком_ на клиенте. И все работает быстро. Даже на атомах особых проблем не было. Я правда IE не тестирую на производительность.

Пишу человеку гордящемуся хелловорлдом. Тысячи их.

Пишу человеку гордящемуся хелловорлдом. Тысячи их.

Ну, в моей «компании гордящейся хелловорлдом» немалая часть разрабов гугла - они тоже генерят представление на клиенте. Так что мне не стыдно.

Ну и еще расскажи ребятам типа - http://knockoutjs.com/ что они лохи, и ничего не понимают в производительности клиентского кода. Ведь ты специалист высшего класса и знаешь как все должно быть.

Ты не совсем понял. Если логика на сервере, то в запросах приходят данные, а обрабатывает их сервер и в зависимости от результата авторизует юзера для чего-нибудь там. Если логика на клиенте, то именно он обрабатывает эти данные, а серверу в запросах идёт результат. В первом случае подделкой запросов можно только всякий бред запилить, а во втором можно плюнуть на проверку данных и в поддельном запросе отправить сразу желаемый результат.

Казалось бы, при чем здесь фреймворк?

Ну если в фреймворке такая дыра, то это его проблема. А если её нет, то это плюс один к карме фреймворка и предмет для маркетингово хвастовства.

Эко вас разнесло милейший, аш два поста нагерерировали. Предлагаю вам подумать над простой задачей - сортировкой пары десятков тысяч записей таблицы на клиенте, быстрым запросам к ней и прочим радостям, данные суммарно занимают в json около 10мб.

А какое эта задача имеет отношение к _представлению_?

Эта задача какраз и занимается созданием представления данных на клиенте.

Аналогичные тормоза с любы сколь угодно сложным интерфейсом, причем жопа растет когда сталкивается с утечками памяти в некоторых бравзерах и прочими разостями.

Такое очучение что автор новости сам ZK не использует в своей практике и новость написал так от нечего делать. Сухо как-то.

#1 Где же упоминание что в 6.0 реализована поддержка прогрессивного паттерна MVVM, кстати нереализованного больше ни в одном java GUI фрэймворке? На мой взгляд MVVM это самая-самая килер фича шестой версии.

#2 Возможности шаблонизации стали ещё гибче.

#3 Прекращена поддержка совместимости с java 1.4, это дает всякие ништяки такие как generics, enums, etc.

#4 Не очень няшная тема оформления которую пилил сам potix на протяжении 4-х лет, была заменена на православную разработанную комьюнити.

#5 Любитилей пописать в MVC стиле то же порадовали добавив CSS 3 style Server side selectors

GWT куда как интереснее - выполнение всей логике на сервере замедляет работу клиента (передача по сети - самая медленная операция) + повышает нагрузку на сервер. А в классе «server-side» библиотек гораздо интереснее Eclipse RAP.

Да GWT конечно интересней, с помощью него можно разрабатывать более эффективные приложения, когда требования к пользовательскому интерфейсу высокие, то лучше выбрать GWT. В то же время как человек одновременно разрабатывающий на обоих фреймворках могу сказать что на GWT разрабатывать намного дольше=дороже, на любом предприятии всегда найдутся RIA приложения в которых фокус ввода не обязан бежать впереди пользователя опережая его мысли и желания, а следовательно мест в ынтерпрайзе где можно применять ZK приложения пока ещё достаточно, ввиду того что это самый быстрый путь создания AJAX приложений, к тому же тотально интегрированный со Spring.

Что же касается Eclipse RAP то это полнейшее слабо-документирование говнище, которое пока еще находится в стадии глубокой разработки, ставить его в один ряд с ZK и GWT пока еще рано, и я сомневаюсь что такой момент когда нибудь наступит, потому что Eclipse RAP уже многие годы пребывает в таком унылом состоянии и ничего к лучшему кардинально не меняется.

Ява? Не годно!

И это написал мембер в профиле которого указано:

Юзер андроида Acer E110 (http://acer-e110.net)

Хех, в то время как все приложения под ведро, чуть менее чем полностью написаны на java.

Какая гадость! Опять жаба! Не нужно! Ф топку!

Взамест ставим:

На клиенте - Java Script/Dojo

На сервере - Python/Django

И становимся щастливы и БЕЗ жабоподелий.

Взамест ставим:

Мозги себе поставь взамест тех что имеешь.

Предлагаю вам подумать над простой задачей - сортировкой пары десятков тысяч записей таблицы на клиенте,

С дуру можно и буй сломать.

Что же касается Eclipse RAP то это полнейшее слабо-документирование говнище, которое пока еще находится в стадии глубокой разработки, ставить его в один ряд с ZK и GWT пока еще рано, и я сомневаюсь что такой момент когда нибудь наступит, потому что Eclipse RAP уже многие годы пребывает в таком унылом состоянии и ничего к лучшему кардинально не меняется.

А какая вам документация нужна?

• книжек по Eclipse RCP масса.
• книжка по RAP есть.
• исходники/примеры/комьюнити.
• интеграция с другими фреймворками возможна, по крайней мере с GWT

Ну и в zk кроме продвинутого виджета табличек ничего интересного нет. Зато есть куча голодных и ни разу не дружных японцев которые за каждый чих просят миску риса.

ZK не является полноценным RIA, заменить десктопные приложения он способен только в системах ввода и визуализации информации о хоз. деятельности, все его виджеты только на это и заточены. Вердикт: использовать только для разработки внутренних интерпрайз приложений и не где более. Плохо масштабируется при большом числе пользователей, так как хранит копию DOM дерева на сервере, а реплицировать такой объект в кластере достаточно дорого, при необходимости обработки событий на клиенте нужно писать javascript, а применение этого быдлоязыка негативно сказывается на качестве и скорости разработки.

Eclipse RAP не серьёзный проект, разрабатывается просто так чтобы был, если это демо серьёзного продукта http://www.eclipse.org/rap/demos/, http://www.eclipse.org/rap/documentation/ а это документация к тому что принято называть продукт, то я балерина. RAP жутко тормозит, документации котэ наплакал, готовых виджетов нет, те виджеты что имеются сложно назвать виджетами, комьюнити нет, success story нет, вердикт не годно для серьезных систем уровня предприятия.

Google Web Toolkit няшка, к тому же от корпорации добра, вердикт: использовать везде.

Плохо масштабируется при большом числе пользователей, так как хранит копию DOM дерева на сервере, а реплицировать такой объект в кластере достаточно дорого.

Это Вы погорячились, использование ZK на не самых маленьких Тайваньской и Гонконских биржах как бы намекает, что над масштабированием ускоглазые изрядно поработали, правда оно не включено в comunity edition. Но за бесплатно используя apache или nginx как фронтэнд можно реализовать такую схему балансировки: запрос пользователя не имеющего сессии направляется на менее загруженный java-appserver, в дальнейшем все запросы с этой сессии будут направляться на этот app-server, конечно балансинг будет не оптимален, но реплицировать ничего не нужно, и еще правда при такой самодельной схеме поломка сервера приводит к потере всех повательской сессий хранящихся на этом сервере, но думаю за бесплатно сойдёт.

Если что и бесит в ZK, так это то что его писали азиаты, качество исходников просто ужасает, о SLAP похоже врят ли кто из разработчиков слышал, повсеместные условия блондинки, вложенность блоков кода на два,три и более уровня, в нескольких файлах eclipse даже обнаружил неиспользуемый импорт. Хотя может у них там в тайване так принято и я придераюсь)

Угу. Зэковский фреймворк.

ZK буржуи читают как Зэт Кей, а не ЗК.

- Кэп.

Посмотри еще в сторону Vaadin. Тоже скажу тебе годнота.

Ну побухти еще что-нибудь

Эта задача какраз и занимается созданием представления данных на клиенте.

Нафига на клиенте представлять одновременно 10000 значений, да еще и отсылать их в неотсортированном виде?

Кстати, даже такая задача возможна - openDatabase, но только это будет webkit-only решение.

утечками памяти в некоторых бравзерах и прочими разостями.

Это верно, но к производительности это имеет вторичное отношение. А возникают они и при просто всяких рюшечках в UI.

Нафига на клиенте представлять одновременно 10000 значений

Вы же сами тут нам рассказывали про мееедлееенный отлик от сервера? Вот кое кто подумал также и решил что лучше все грузить клиенту.

Вы же сами тут нам рассказывали про мееедлееенный отлик от сервера? Вот кое кто подумал также и решил что лучше все грузить клиенту.

Вы затрагиваете самый радикальный случай и экстраполируете его. На самом деле необходимость редактировать и отображать большие сложные иерархические объекты возникает гораздо реже чем необходимость редактировать и отображать простые формочки, поэтому обработка событий на клиенте в большинстве случаев быстрее нежели посылка http запроса на каждый чих к серверу.

На правах треда. Кто нибудь задумывался над генерацией формочек по схеме данных, например с помощью Scala или Clojure?

повсеместные условия блондинки

Если что и бесит в ZK, так это то что его писали азиаты, качество исходников просто ужасает, о SLAP похоже врят ли кто из разработчиков слышал, повсеместные условия блондинки, ...

ммм. Что такое условие блондинки?

На правах треда. Кто нибудь задумывался над генерацией формочек по схеме данных, например с помощью Scala или Clojure?

А имеет ли это смысл при программировании на java? Вроде бы уже есть адин эс и иже с ним, в которых автогенерация ниразунеудобного пользовательского интерфейса поставлена на поток. ZK позволяет писать контроллеры на clojure и scala, со scala правда дела намного лучше и бурно развивается отдельный проект zk-scala.

Хотя кстати да задумывался на прошлой работе, когда работал над отчетной системой, но не над самой идеей автогенерации интерфейса, так как большие боссы тебя за автосгенирированное поделие просто из окна выкинут, а больше думал об динамическом создании интерфейса приложения без необходимости его передеплоя.

ммм. Что такое условие блондинки?

Это когда птушники пишут в таком стиле:

if (какое_то_условие_выполнеяется) {
   // делаем что-то
} else {
   throw ... // кидаем какоенить исключение
}

if (какое_то_условие_не_выполнеяется) {
   // кидаем какоенить исключение
}
// делаем что-то

Какая гадость! Опять жаба! Не нужно! Ф топку!
Взамест ставим:

На клиенте - Java Script/Dojo

На сервере - Python/Django

И становимся щастливы и БЕЗ жабоподелий.

То что ты долбоёб, быдло и хуесос это и так у тебя на ебальнике написано, срать в комментах про технологии в которых ты ничего не понимаешь, для этого вовсе не обязательно, любой всё про тебя и так узнает при личном собеседовании, как только ты откроешь рот в своей безмозглой башке. Но я всё таки стараюсь видеть лучшее в людях, и поэтому дал бы тебе совет брать пример со стэндарт и синиор разработчиков на python, которые прочли эту новость ровно до той половины в которой написано что она про java, затем с мыслью что оно мне не надо равнодушно перешли на следущую новость.

«Зэт Кей» - Zаключенный Каналоармеец :)

а что на клиентской стороне??? хз, может попробую :)

а что на клиентской стороне??? хз, может попробую :)

На клиентской стороне jquery 1.6.4 + js библиотека от zk построенная поверх jquery, до семерки jquery пока не обновились, но это наверно это не так важно, так как за 3 года программирования на ZK я не разу не столкнулся с необходимостью писать JS руками, оптимизация клиентской стороны между релизами проходит как бы за кадром и ничего в java коде не меняется.

Если логика на клиенте, то именно он обрабатывает эти данные

Ты не совсем понял. Если логика на сервере, то в запросах приходят данные, а обрабатывает их сервер и в зависимости от результата авторизует юзера для чего-нибудь там. Если логика на клиенте, то именно он обрабатывает эти данные, а серверу в запросах идёт результат. В первом случае подделкой запросов можно только всякий бред запилить, а во втором можно плюнуть на проверку данных и в поддельном запросе отправить сразу желаемый результат.

Ебаться в теливизор, ты где такой код вообще видел-то, в каких компаниях, имена лидов, явки, фамилии? Сервер всегда перепроверяет все входящие данные, независимо от того, что клиент часть проверок уже выполнил, то есть некоторое дублирование всегда имеем, иначе проще клиенту сразу выдать JDBC-HTTP proxy например от inetsoftware и пусть колбасит на полную катушку на прямую из джаваскрипта, хули там городить ненужных посредников в виде ничего не делающего сервера приложений.

Вы же сами тут нам рассказывали про мееедлееенный отлик от сервера?

Он медленный, если это не интранет. И я не предлагал все делать на клиенте. Я предлагал на клиенте заниматься _представлением_ - например базовой валидацией. Проблема «чисто серверного » подхода что даже если нам надо просто проверить что сумма меньше заданной или добавить стиль пр клике - нужно будет делать запрос на сервер вместо тривиальной логики на клиенте, в которую трансилирует GWT.

А тупо отдать 10000 значений это проблема уже потому, что эти данные могут меняться со временем и их надо синхронизовать постоянно. И за 10 метровый JSON тебя проклянут все пользователи мобильного интернета. А если подразумевается работа только в интранете, непонятно зачем выносить с сервера такую логику:латенси запроса крайне мало, как и число пользователей.

Он медленный, если это не интранет.

Хорошо подмеченна проблема серверного подхода, в случае ZK и логики на клиенте, в этом случае чтобы избежать тормозов приходится писать быдлячий javascript, это основная Ахиллесова пята ZK, так как в случае GWT программировать на этом бутофорском языке для плюшевых разработчиков необходимости не возникает. Хотя опять же если дело ограничивается локальной сетью то на JS можно и не писать, ZK отлично справляется с допустим хитрой табуляцией фокуса ввода через сервер, в локальной сети пользователь косяков не замечает, так как обработка HTTP запроса происходит быстрее чем его чувства осязания способны воспринять, но скажем когда юзер в Сочи а сервер в Квибеке, то уже пользователь начнёт ощутимо ощущать что интерфейс слегка подтормаживает.

новость написал так от нечего делать

Такое очучение что автор новости сам ZK не использует в своей практике и новость написал так от нечего делать.

Что есть, то есть, я не знаю как минусовать карму, но заминусовал бы автора по самое нихочу, он даже не удосужился перевести what is new 6.0 с оф. сайта, это при том что релиз ZK-6.0.0 состоялся 14 февраля, а сегодня на дворе 23 апреля. Личное мнение автора относительно новых фишек отсутсвует, что как бы да подтверждает что он посторонний по отношению к ZK, похоже что автор передрал новость с какого-нибудь англоязычного ресурса.

Если бы неистрибимый в России дух джавасрача в красноглазом сообществе, то тема бы утонула, но ведь пошла же ведь, и как пошла:

То что ты долбоёб, быдло и хуесос это и так у тебя на ебальнике написано, ...