Коллеги, есть ли тут кто, имеющий опыт построения реального приложения
на Vaadin?
Что интересует конкретно — годится ли оно в своём современном состоянии
для достаточного развесистого приложения (скажем так, 50-100 разных
экранов)?
И я пока не очень понял концепцию — с точки зрения браузера это single
page application? Если да, то не будет ли в нём при более-менее
длительной работе "течь" память на клиенте?
Если нет, то как оно разбивается на отдельные "страницы"?
Теорию я сейчас сам почитаю ) , интересует именно практический опыт.
да single page applicaiton,но каждое действие, каждый клик вроде бы обрабатывается на сервере, маленьким ajax запросом, даже если это просто изменение ui. Т.е. другая концепция нежели чем gwt и т.д.
Здравствуйте, hrensgory, Вы писали:
H>Коллеги, есть ли тут кто, имеющий опыт построения реального приложения H>на Vaadin?
иа. на 6ой версии.
H>Что интересует конкретно — годится ли оно в своём современном состоянии H>для достаточного развесистого приложения (скажем так, 50-100 разных H>экранов)?
вполне. только УИ придется программировать в аля свинг API + абстрактный датабиндинг всего. После шаблонизаторов на яваскрипте + верстальщик это просто ужос полный. Хотя если нужны табличка + формочка для crud то вполне ок
H>И я пока не очень понял концепцию — с точки зрения браузера это single H>page application? Если да, то не будет ли в нём при более-менее H>длительной работе "течь" память на клиенте?
не замечал. выделенная память прямо пропорциональна отображаемому на экране УИ. Значительных утечек не видел. Огромные таблицы на полуавтоматической пагинации кушают совсем мало на клиенте. +халявный сортинг и другие плюшки при правильно написаном датабиндинге. адаптерами к гибернейту и другим вещам не пользовался не знаю.
H>Если нет, то как оно разбивается на отдельные "страницы"?
в целом — руками. в 7ой версии обещают весь стейт отвязать от странички и поддерживать многовкладачность. На практике теперь корень называется UI, а не Application. больше особо разницы что то не видать.
H>Теорию я сейчас сам почитаю ) , интересует именно практический опыт.
отличная штука для админок в интранете к ява апликейшнам. для всего остального практически не пригодна либо из за больших трудозатрат на рисование UI либо из-за технических ограничений хранения всего стейта на сервере
В портальные решения вполне встраивается, на фоне остальных тормозов не особо даже и заметно.
Тяжко кастомизировать, фактически для любого нестандартного контрола придется не просто на gwt/html/javascript писать, но и еще с фреймворком интегрироваться. Судя по адовым срокам неоднократно сорванным по выходу 7ой версии это очень нетривиальная задача.
А еще верстальщики сильно матерятся на встроенный подход к именованию и вложению цсс классов. Почему — не знаю. Феншуй не тот.
On 11.02.2013 19:04, dotidot wrote:
> После шаблонизаторов на яваскрипте + верстальщик это > просто ужос полный. Хотя если нужны табличка + формочка для crud то > вполне ок
Да, примерно оно и есть. CRUD в основном.
> H>И я пока не очень понял концепцию — с точки зрения браузера это single > H>page application? Если да, то не будет ли в нём при более-менее > H>длительной работе "течь" память на клиенте? > не замечал. выделенная память прямо пропорциональна отображаемому на > экране УИ. Значительных утечек не видел. Огромные таблицы на > полуавтоматической пагинации кушают совсем мало на клиенте. +халявный > сортинг и другие плюшки при правильно написаном датабиндинге.
А как его писать правильно? Биндиться напрямую к объектам,
конструируемым из БД (JPA/Hibernate) не хочется, думаем более
легковесные DTO сделать.
> H>Теорию я сейчас сам почитаю ) , интересует именно практический опыт. > отличная штука для админок в интранете к ява апликейшнам. для всего > остального практически не пригодна либо из за больших трудозатрат на > рисование UI либо из-за технических ограничений хранения всего стейта на > сервере
Так и планируем использовать, для админки.
> А еще верстальщики сильно матерятся на встроенный подход к именованию и > вложению цсс классов. Почему — не знаю. Феншуй не тот.
Хочется как раз попробовать обойтись в админке без верстальщика. По
крайней мере в первой версии )
On 11.02.2013 18:19, insighter wrote:
> да single page applicaiton,но каждое действие, каждый клик вроде бы > обрабатывается на сервере, маленьким ajax запросом, даже если это просто > изменение ui. Т.е. другая концепция нежели чем gwt и т.д.
Здравствуйте, hrensgory, Вы писали:
H>А как его писать правильно? Биндиться напрямую к объектам, H>конструируемым из БД (JPA/Hibernate) не хочется, думаем более H>легковесные DTO сделать.
долго и мучительно
шучу, на самом деле основная фишка ваадина как раз в том что дто не нужны. объекты на клиент не передаются только содержимое формочек.
сбиндите хибернейтовские объекты там утилиты для этого есть. даже в формочках будет валидация по аннотациям.
>> да single page applicaiton,но каждое действие, каждый клик вроде бы >> обрабатывается на сервере, маленьким ajax запросом, даже если это просто >> изменение ui. Т.е. другая концепция нежели чем gwt и т.д.
H>JSF прям. Спасибо за информацию !
На JSF не похоже, больше похоже на ExtGwt, но и это не так По умолчанию, пишется серверная сторона, может только в этом схоже с JSF. Опять же можно писать и клиентскую сторону как в ExtGwt, но довольно сложнова-то.
Но при всём при этом, я выбрал этот продукт в качестве фронтэнда для корпоративного портала. Порталу уже 2 года, полёт нормальный
On 11.02.2013 21:15, dotidot wrote:
> H>А как его писать правильно? Биндиться напрямую к объектам, > H>конструируемым из БД (JPA/Hibernate) не хочется, думаем более > H>легковесные DTO сделать. > долго и мучительно > шучу, на самом деле основная фишка ваадина как раз в том что дто не > нужны. объекты на клиент не передаются только содержимое формочек. > сбиндите хибернейтовские объекты там утилиты для этого есть. даже в > формочках будет валидация по аннотациям.
Спасибо за ответы, будем пробовать )
Ещё вопрос — в первом письме вы писали, что на ваадине хороши
интРАнетовские админки. Имеется в виду, что трафик между клиентом и
сервером довольно интенсивный? У нас просто не вполне интранет-решение
планируется, хотя пользователей у админки будет немного и каналы до
сервера у них будут хорошие.
H>сервером довольно интенсивный? У нас просто не вполне интранет-решение H>планируется, хотя пользователей у админки будет немного и каналы до H>сервера у них будут хорошие.
да кто щас ширину считает. лаги сильно заметные будут если пинг до сервера не минимальный. там ж буквально на каждое изменение кроме трививальных (а в старых версиях даже перемещение окошка по экрану через сервер шло) идет запрос на сервер, а оттуда ответ что перерисовать.
и пока не придет справа вверху желтый спиннер крутится периодически превращаясь в красный. на мобильном интернете лаги просто ужасные, хотя трафик десятки килобайт всего за минуты работы.
cделайте демо и оцените на месте, это буквально пара строк. главное смотреть со стороны клиентов на лаги, а не на локалхосте.
Здравствуйте, dotidot, Вы писали:
H>>Если нет, то как оно разбивается на отдельные "страницы"? D>в целом — руками. в 7ой версии обещают весь стейт отвязать от странички и поддерживать многовкладачность. На практике теперь корень называется UI, а не Application. больше особо разницы что то не видать.
7ку уже зарелизили, судя по описанию добавили кучу всего
Здравствуйте, bykka, Вы писали:
B>У нас в компании выбрали SmartGWT так как набор компонентов намного больше.
И как? Много сделали? Меня глюки в гридах напрягают. В демках всё стабильно и красиво. Как сделал у себя с JSON с минимальными наворотами, так началась трудноотлавливаемая мистика.
Здравствуйте, Blazkowicz, Вы писали:
B>>У нас в компании выбрали SmartGWT так как набор компонентов намного больше. B>И как? Много сделали? Меня глюки в гридах напрягают. В демках всё стабильно и красиво. Как сделал у себя с JSON с минимальными наворотами, так началась трудноотлавливаемая мистика.
Ну вот как раз с гридами пока проблем нету. Есть проблема з диалоговим окном логин формы — в мозиле постоянно почему-то появляется вертикальний скролин, плюс все формы нормально работают, а в одной форме, когда делаешь disable для полей, ну что-то никак нормально стили не может применить и показать, что она задизейбленна.
Кстати, раз пошел такой разговор, что думаете еще о zkoss? Набор компонентов вроде тоже большой.
(Primefaces я не считаю — набор комнонентов хоть и достаточно большой, но вот только нужно попотеть перед тем как заставить их виглядеть "гармонично" друг с другом)
On 12.02.2013 17:06, bykka wrote: > From: *bykka* </Users/80701.aspx>
> Кстати, раз пошел такой разговор, что думаете еще о zkoss? Набор > компонентов вроде тоже большой.
Выглядит красиво, но когда пробовали на практике — не работал. Правда
это было давно.
Здравствуйте, hrensgory, Вы писали:
H>Выглядит красиво, но когда пробовали на практике — не работал. Правда H>это было давно.
Я работал с ZKOSS около двух лет.
Работает нормально, программы пишутся быстро и экраны выглядят красиво.
Но проект мы успешно завалили — заказчику не понравилась скорость реакции приложения.
Не для всякого приложения ZKOSS пригоден, однако. :(
Здравствуйте, hrensgory, Вы писали:
H>Коллеги, есть ли тут кто, имеющий опыт построения реального приложения H>на Vaadin?
Есть такой опыт.
H>Что интересует конкретно — годится ли оно в своём современном состоянии H>для достаточного развесистого приложения (скажем так, 50-100 разных H>экранов)?
Годится. В моем опыте — 99 процентов реальных компонентов (страниц) не требуют написания клиентского кода. Клиентское программирование требует только для
1. Нестандартная графика,
2. Обработка действий пользователя очень с высокой отзывчивостью
3. Минимизация трафика за счет клиентского состояния (для большого и интенсивно обновляемого динамического контента)
Модель программирования Server-side имеет много преимуществ. Сразу забываешь о DTO, пишешь, не задумываясь о передаче данных, словно это десктопное приложение. Можешь использовать любые java-библиотеки (в отличие от GWT или того хуже, javascript). Просто сказка. Производительность труда возрастает в 3-5 раз.
H>И я пока не очень понял концепцию — с точки зрения браузера это single H>page application? Если да, то не будет ли в нём при более-менее H>длительной работе "течь" память на клиенте? H>Если нет, то как оно разбивается на отдельные "страницы"?
Открой класс VaadinServlet, метод service. При самом первом request вызывается метод handleOtherRequest, в котором вызывается BootstrapHandler. BootstrapHandler как следует из названия формирует bootstrap-страницу. Примерный фрагмент этой страницы:
<html>
<head>
<script type="text/javascript" src="./VAADIN/vaadinBootstrap.js"></script>
<script type="text/javascript">
if (!window.vaadin) alert("Failed to load the bootstrap javascript: ./VAADIN/vaadinBootstrap.js");
vaadin.initApplication("cassandra-1073564104")</script>
</body>
</html>
Если говорить упрощенно, то выше приведен чуть ли не единственный html, возвращаемый vaadin. Все прочие данные передаются уже в виде json. Как видим, вызвается функция initApplication из файла vaadinBootstrap.js, которая одним аякс-запросом загружает json начального состояния UI (см. метод handleBrowserDetailsRequest CommunicationManager-a). Иными словами, метод handleBrowserDetailsRequest инстанциирует весь пользовательский код, создавая пользовательский объект UI и возвращает состояние этого UI json-ом. В будущем полное состояние страницы уже не передается, а передаются только изменения. В этом заключается киллер-фича vaadin — передаются только изменения, полного обновления не происходит. Метод handleVariables того же communication manager опрашивает контролы на предмет изменений и возвращает json с изменениями, который применяется к существующему состоянию страницы.
Социализм — это власть трудящихся и централизованная плановая экономика.
On 18.04.2013 17:44, LaPerouse wrote:
> 2. Обработка действий пользователя очень с высокой отзывчивостью > 3. Минимизация трафика за счет клиентского состояния (для большого и > интенсивно обновляемого динамического контента)
Здравствуйте, hrensgory, Вы писали:
H>On 18.04.2013 17:44, LaPerouse wrote:
>> 2. Обработка действий пользователя очень с высокой отзывчивостью
Server-Side модель подразумевает, что весь UI-код исполняется на сервере. На клиент пересылаются json-ом изменения в UI (как это происходит — см. в предыдущем сообщении). Конечно, callback-и (listener-ы) тоже выполняются на сервере. Если требуется высокая степень интерактивности, то постоянные обращения к серверу могут стать проблемой (но не становятся в большинстве случаев). Проблема устраняется просто — написанием своей клиентской компоненты на GWT. Новый Vaadin 7 существенно расширяет поддержку пользовательского клиентского кода, который теперь может произвольно обращаться к серверу при помощи механизма RPC.
>> 3. Минимизация трафика за счет клиентского состояния (для большого и >> интенсивно обновляемого динамического контента)
Сравним по трафику два подхода.
1. Традиционный GWT: клиентский код пользователя (разработчика) запрашивает данные и на основании полученных данных производит манипуляции над пользовательским интерфейсом
2. Vaadin: пользовательский код на сервере производит манипуляции над пользовательским интерфейсом и vaadin передает результирующие изменения UI на клиент, где клиентский рантайм автоматически применяет эти изменения.
Обычно соотношение трафика 1 и 2 примерно на уровне 1.5-2. Однако в некоторых случаях небольшие изменения в данных могут вызвать большие изменения в пользовательском интерфейсе. Например, изменилось одно свойство объекта и это вызвало добавление новой панели (случай А). Или же отношение данных и изменений интерфейса нормальное (1.5-2), но при этом данные передаются очень часто (случай Б). И тот, и другой случай разруливаются клиентским кодом. В случае А просто напросто строишь UI на клиенте, получая вручную данные. В случае Б просо-напросто поддерживаешь параллельное состояние на клиенте, избегая лишних запросов данных.
В обеих случаях (2 и 3) написание клиентского кода и интеграция его с серверным кодом намного проще чистого GWT. Vaadin представляет полную поддержку этого процесса. И еще, как я говорил, требутся это совсем нечасто.
Социализм — это власть трудящихся и централизованная плановая экономика.
