Коллеги, есть ли тут кто, имеющий опыт построения реального приложения
на 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 представляет полную поддержку этого процесса. И еще, как я говорил, требутся это совсем нечасто.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, GiDRAvlic, Вы писали:
GDR>Здравствуйте, dotidot, Вы писали:
H>>>Если нет, то как оно разбивается на отдельные "страницы"? D>>в целом — руками. в 7ой версии обещают весь стейт отвязать от странички и поддерживать многовкладачность. На практике теперь корень называется UI, а не Application. больше особо разницы что то не видать.
GDR>7ку уже зарелизили, судя по описанию добавили кучу всего
Если у кого есть существующие разработки на vaadin 6, я бы предостерег бросаться портировать на vaadin 7 прямо сейчас. Текущая версия сыровата. Но новые проекты, разумеется, нужно начинать на седьмой версии.
Социализм — это власть трудящихся и централизованная плановая экономика.
H>Теорию я сейчас сам почитаю ) , интересует именно практический опыт.
Использовал (уже было это legacy). В трезвом уме никогда бы не взял его в начальный проект (даже без опыта использования).
* Если вдруг у вас сотрудник посередине рабочего дня ушел в отпуск и потом вернулся, ваадиновская сессия будет потеряна. Соответственно, сотрудник будет созерцать "take note on unsaved data" без возможности повторить операцию (нужно запускать приложение и все делать ручками)
* Фильтрация на клиенте списка через сервер (банальная фильтр по подстроке, сокращает выбор из списка)
* Я completion так сделать и не смог нормальный (выбор в одном поле может заполнять несколько полей). Он к чему-то какими-то гвоздями прибит. Т.е. "модель" + "визуализатор" оно сделать не смогло. Это даже не говоря о том, чтобы выделять найденную подстроку.
* Zoom-in + Zoom-out приводит к потрясающим скроллбарам на каждом компоненте
* Layout клиента в пикселях (не понятно, на каком шрифте вычисленных)... Поэтому ХЗ, что и куда поедет.
* Вообще Layout отлаживать нетривиально.
* У них была какая-то забористая трава, когда они сочиняли таблицы. У колонок таблицы и у набора полей в одной строке своя отдельная жизнь. Для реализации таблицы нужно 3 модели реализовать (минимум!).
* Валидация у таблиц приниципиально отсутствует (т.е. непонятно, куда ее отображать).
* Судя по всему, "form validation" прибит гвоздями к фреймворку. И его отображение — тоже. Поэтому если я хочу выводить все warnings в отдельной области, нужно постараться.
* Их Property как-то странно типизированы. Половина property сделана generic (то ли method property, то ли что-то еще). Зато сам интерфейс property работает с object. А еще в этом Property есть метод setReadOnly. Рационального объяснения наличию такого метода в интерфейсе Property я не нашел.
* С клавиатурой плохо дружит. Какие-то окна пооткрывал, потом позакрывал. Потом нажал пробел. Интерфейс куда-то пропал (небольшой кусок где-то было видно, остального — нет).
* В 7-ке появилась куча статических аксессоров и черной магии. Например, у нас упали несколько тестов UI-компонентов. Там где-то конвертеры (то ли статические, то ли threadlocal) не зарегистрировались.
* Я не понял, как в application что-нибудь нормально заинжектить (глобальный на все приложение объект/коннектор/пул и т.п.). В сервлетах я это могу из startup listener поднять (вместе с сервлетами ). Как в vaadin'е — так сразу и не нашел. Если знаете, делитесь информацией.
* Я не разбирался, что там с security. Можно ли какой-нибудь запрос куда-нибудь подменить. И как оно с текущим Application связано.
* Challenge/response authentication не так просто изобразить. Нужно кастомный клиентский компонент писать. Брать challenge/response или пересылать пароль по http(s) — другой вопрос.
* Что-нибудь глобальное на клиенте прикрутить к сети — то еще приключение (в GWT, впрочем, тоже). Хотелось бы какое-нибудь банальное окно "а у вас связи нет" выводить с возможностью повторить запрос, например.
* Касательно аутентификации. Single-page application не дает сделать более менее безопасную галочку "save password". Нет, я понимаю, что это сразу небезопасно. Но хотя бы по сети этот токен не гонять на каждый запрос, а только при входе (банальный workflow: request -> redirect <...>/auth -> redirect application). Кука с долгоиграющим токеном дается только на <...>/auth и не светится в каждом обмене.
Вот как-то так. Это на маленьком простом приложении. Может, еще чего забыл.
19.04.2013 19:32, maxkar пишет: > > H>Теорию я сейчас сам почитаю ) , интересует именно практический опыт. > > Использовал (уже было это legacy). В трезвом уме никогда бы не взял его > в начальный проект (даже без опыта использования). >
Здравствуйте, maxkar, Вы писали:
H>>Теорию я сейчас сам почитаю ) , интересует именно практический опыт.
M>Использовал (уже было это legacy). В трезвом уме никогда бы не взял его в начальный проект (даже без опыта использования).
Мы сейчас пилим что-то вроде ERP на vaadin. ИМХО, это лучшее что пробовали. Во всех остальных случаях гемора было в разы больше.
M> * Если вдруг у вас сотрудник посередине рабочего дня ушел в отпуск и потом вернулся, ваадиновская сессия будет потеряна. Соответственно, сотрудник будет созерцать "take note on unsaved data" без возможности повторить операцию (нужно запускать приложение и все делать ручками)
Да, это засада. У себя решили увеличением жизни сессии
M> * Фильтрация на клиенте списка через сервер (банальная фильтр по подстроке, сокращает выбор из списка)
Ну так это нормально. Vaadin серверный фреймворк. Никаких проблем с этим не наблюдается.
M> * Я completion так сделать и не смог нормальный (выбор в одном поле может заполнять несколько полей). Он к чему-то какими-то гвоздями прибит. Т.е. "модель" + "визуализатор" оно сделать не смогло. Это даже не говоря о том, чтобы выделять найденную подстроку.
Тут вообще вроде нет проблем. Может поясните на примере, что было проблемой?
M> * Zoom-in + Zoom-out приводит к потрясающим скроллбарам на каждом компоненте
Такой проблемы не было ни разу. Пишем проект начиная с версии 6.5. Сейчас переводим на 7-ку. Вероятно вы что-то не так делаете.
M> * Layout клиента в пикселях (не понятно, на каком шрифте вычисленных)... Поэтому ХЗ, что и куда поедет.
Так же не сталкивались. Даже если это и так, то проблем это не дает ни каких.
M> * Вообще Layout отлаживать нетривиально.
Зачем их вообще отлаживать? Какая-то надуманная проблема )
M> * У них была какая-то забористая трава, когда они сочиняли таблицы. У колонок таблицы и у набора полей в одной строке своя отдельная жизнь. Для реализации таблицы нужно 3 модели реализовать (минимум!).
Какие 3 модели? Вы собственные реализации таблиц делаете? Для обычного использования таблиц об этом вообще не думаешь.
M> * Валидация у таблиц приниципиально отсутствует (т.е. непонятно, куда ее отображать).
Ни разу не потребовалось. Не подскажете юзкейс где оно надо?
M> * Судя по всему, "form validation" прибит гвоздями к фреймворку. И его отображение — тоже. Поэтому если я хочу выводить все warnings в отдельной области, нужно постараться.
Да, это тоже засада. У одного заказчика операторы "не видели" ярко красный кружок с восклицательным знаком возле ошибочного поля)))
M> * Их Property как-то странно типизированы. Половина property сделана generic (то ли method property, то ли что-то еще). Зато сам интерфейс property работает с object. А еще в этом Property есть метод setReadOnly. Рационального объяснения наличию такого метода в интерфейсе Property я не нашел.
А вот мы везде используем этот метод. Ибо удобно закрывать то что надо.
M> * С клавиатурой плохо дружит. Какие-то окна пооткрывал, потом позакрывал. Потом нажал пробел. Интерфейс куда-то пропал (небольшой кусок где-то было видно, остального — нет).
Думаю вы что-то накосячили с ней ибо вот от этого момента вообще тащимся, вместе с заказчиками. Т.к. работа с клавой настолько хорошая, что оператор может работать клавой, БЕЗ МЫШКИ!, в браузере! Раньше такое получалось только в десктоп приложениях. Операторам реально нравится.
M> * В 7-ке появилась куча статических аксессоров и черной магии. Например, у нас упали несколько тестов UI-компонентов. Там где-то конвертеры (то ли статические, то ли threadlocal) не зарегистрировались.
Тут не могу пояснить, ибо во внктрях небыло необходимости копаться. Все и так отлично работает.
M> * Я не понял, как в application что-нибудь нормально заинжектить (глобальный на все приложение объект/коннектор/пул и т.п.). В сервлетах я это могу из startup listener поднять (вместе с сервлетами ). Как в vaadin'е — так сразу и не нашел. Если знаете, делитесь информацией.
Ну это вообще детский сад. Про статик сами найдете где почитать, или подсказать? ))) Хотя у нас на спринге все инжектится, и проблем нет.
M> * Я не разбирался, что там с security. Можно ли какой-нибудь запрос куда-нибудь подменить. И как оно с текущим Application связано.
Серверный же фреймворк. Вместе со Spring Security проблем никаких.
M> * Challenge/response authentication не так просто изобразить. Нужно кастомный клиентский компонент писать. Брать challenge/response или пересылать пароль по http(s) — другой вопрос.
Опять же, поясните, что именно у вас не получилось?
M> * Что-нибудь глобальное на клиенте прикрутить к сети — то еще приключение (в GWT, впрочем, тоже). Хотелось бы какое-нибудь банальное окно "а у вас связи нет" выводить с возможностью повторить запрос, например.
Да, это тоже засада. Вроде как в 7-й версии можно перехватить это событие, и как-то обработать. Еще не до конца разобрались.
Так же в 7-й версии теперь можно писать клиентские приложения без сервера, возможно в этом направлении и надо покопать.
M> * Касательно аутентификации. Single-page application не дает сделать более менее безопасную галочку "save password". Нет, я понимаю, что это сразу небезопасно. Но хотя бы по сети этот токен не гонять на каждый запрос, а только при входе (банальный workflow: request -> redirect <...>/auth -> redirect application). Кука с долгоиграющим токеном дается только на <...>/auth и не светится в каждом обмене.
Это уже не актуально. 7-я версия уже не Single-page application.
M>Вот как-то так. Это на маленьком простом приложении. Может, еще чего забыл.
Мы сделали 4 проекта на Vaadin. 2 из них это админки, хотя и довольно разувесистые.
Один проект, что-то вроде 1С торговля и склад. И самый большой проект щас пилим. Что-то вроде ERP.
До этого был стандартный подход. Клиент отдельно, сервисы отдельно и т.д.
После этого дикого, не прекращающегося кошмара с верстальщиками и прочей фигней, просто вздохнули спокойно.
Вопросы типа "а у нас тут поехала форма логина в новом фирефоксе" или "почему в эксплорере, только после 3-4 перезагрузок страницы все начинает работать" просто исчезли как класс. Скорость разработки прототипа, а потом проекта на нем, возросла реально в разы.
Да, это не идеальная технология. Да таких и не бывает в природе. Но делать на ваадине всякие админки и интерпрайзные решения просто офигенно удобно. Быстро, эффективно, много готовых компонентов.
И кстати, на ERP многие работают с планшетов через GPRS. Проблем нет вообще. Некоторые даже умудряются с мобильников там что-то делать)
Здравствуйте, tumblerrr, Вы писали:
M>>Использовал (уже было это legacy). В трезвом уме никогда бы не взял его в начальный проект (даже без опыта использования). T>Мы сейчас пилим что-то вроде ERP на vaadin. ИМХО, это лучшее что пробовали. Во всех остальных случаях гемора было в разы больше.
Javascript + reactive bindings поудобнее будет для сложных приложений, imho. Да, порог вхождения чуть побольше (нужно начальную библиотеку написать на клиенте), потом все удобнее.
M>>Если вдруг у вас сотрудник посередине рабочего дня ушел в отпуск и потом вернулся, ваадиновская сессия будет потеряна. Соответственно, сотрудник будет созерцать "take note on unsaved data" без возможности повторить операцию (нужно запускать приложение и все делать ручками) T>Да, это засада. У себя решили увеличением жизни сессии
Угу, workaround. Правильный stateless ajax данной проблемой вообще не страдает и позоволяет прекрасно переаутентифицироваться и повторить запрос. Причем для клиента это делается ровно один раз на все приложение.
M>> * Фильтрация на клиенте списка через сервер (банальная фильтр по подстроке, сокращает выбор из списка) T>Ну так это нормально. Vaadin серверный фреймворк. Никаких проблем с этим не наблюдается.
Визуально тормозит. Вот я вижу и мне неприятно. А на javascript не тормозит.
M>> * Я completion так сделать и не смог нормальный (выбор в одном поле может заполнять несколько полей). Он к чему-то какими-то гвоздями прибит. Т.е. "модель" + "визуализатор" оно сделать не смогло. Это даже не говоря о том, чтобы выделять найденную подстроку. T>Тут вообще вроде нет проблем. Может поясните на примере, что было проблемой?
О! Давайте. Есть три поля. Сервер, логин и пароль. Делаем completion. В поле сервера предлагаются к заполнению сервера с логином и паролем. Т.е. для каждого сервера мы имеем записи вида "только сервер", "севрер с логином", "сервер с логином и паролем". Пар "сервер с логином и сервер с логином и паролем" может быть несколько, если несколько логинов. Соответственно, при выборе пункта мы заполняем только сервер, сервер и логин, сервер, логин и пароль. Аналогично в completion для логина — есть вариант без пароля и с паролем (пароль в completion не отображается). А еще в эти поля есть free input. Как подобный completion делать? Бонусный вопрос — почему filter для completion это int а не реализация интерфейса? Может, я хочу свою реализацию фильтрации.
M>> * Zoom-in + Zoom-out приводит к потрясающим скроллбарам на каждом компоненте T>Такой проблемы не было ни разу. Пишем проект начиная с версии 6.5. Сейчас переводим на 7-ку. Вероятно вы что-то не так делаете.
Ничего специального. Где-то верстка зачем-то в пикселях, может, что-то в CSS. Отлаживать ваадин и искать "что мы не так делаем" совсем не хочется. Нормальная библиотека должна уметь сказать об этом гораздо раньше.
M>> * Layout клиента в пикселях (не понятно, на каком шрифте вычисленных)... Поэтому ХЗ, что и куда поедет. T>Так же не сталкивались. Даже если это и так, то проблем это не дает ни каких.
Угу. Особенно когда какой-то фрагмент формочки почему-то не видно (это умный vaadin поставил overflow:hidden).
M>> * Вообще Layout отлаживать нетривиально. T>Зачем их вообще отлаживать? Какая-то надуманная проблема )
См. выше. Какое-то поле (заголовок, например), выводится не полностью.
M>> * У них была какая-то забористая трава, когда они сочиняли таблицы. У колонок таблицы и у набора полей в одной строке своя отдельная жизнь. Для реализации таблицы нужно 3 модели реализовать (минимум!). T>Какие 3 модели? Вы собственные реализации таблиц делаете? Для обычного использования таблиц об этом вообще не думаешь.
Да, конечно свои. "Простой" CRUD к базе не интересен. Нужен биндинг к части модели (в модели есть growable список некоторый). Вот и выясняется, что "шаг влево/шаг вправо — большой геморрой".
M>> * Валидация у таблиц приниципиально отсутствует (т.е. непонятно, куда ее отображать). T>Ни разу не потребовалось. Не подскажете юзкейс где оно надо?
Числа из определенного диапазона в таблицу вводить и прочие ограничения домена. Требовать уникальность строк в таблице. Еще что-нибудь. Мало ли какой кусок модели я хочу выводить.
M>> * Их Property как-то странно типизированы. Половина property сделана generic (то ли method property, то ли что-то еще). Зато сам интерфейс property работает с object. А еще в этом Property есть метод setReadOnly. Рационального объяснения наличию такого метода в интерфейсе Property я не нашел. T>А вот мы везде используем этот метод. Ибо удобно закрывать то что надо.
А вы переопределяете метод setReadOnly после этого, чтобы он выбрасывал исключения? Не боитесь, что ваадин потом вызовет setReadOnly(false) и все ваши усилия пойдут прахом? Причем наличие такого метода как раз свидетельствует о том, что фреймворк может хотеть это сделать (тем более, что уведомления об изменениях уже mixin'ами). Можно ведь сделать и "чистое" API. Банально сделать setReadonly у всех стандартных реализаций (вроде method property и какие там еще есть), а не тащить в общий интефрейс.
M>> * С клавиатурой плохо дружит. Какие-то окна пооткрывал, потом позакрывал. Потом нажал пробел. Интерфейс куда-то пропал (небольшой кусок где-то было видно, остального — нет). T>Думаю вы что-то накосячили с ней ибо вот от этого момента вообще тащимся, вместе с заказчиками. Т.к. работа с клавой настолько хорошая, что оператор может работать клавой, БЕЗ МЫШКИ!, в браузере! Раньше такое получалось только в десктоп приложениях. Операторам реально нравится.
Дополнительные диалоговые окна не пробовали мышкой закрывать и потом "пробел" нажимать? Если особо не извращаться, все нормально. А вот как только фокус остался в "неопределенном" состоянии, начались проблемы. Ну и "где-то накосячили" особо искать не хочется. Я не люблю фреймворки, в можно легко накосячить. Библиотеки — люблю, потому что у них можно легко и просто управлять scope их использования. А вот frameworks — нет.
M>> * В 7-ке появилась куча статических аксессоров и черной магии. Например, у нас упали несколько тестов UI-компонентов. Там где-то конвертеры (то ли статические, то ли threadlocal) не зарегистрировались. T>Тут не могу пояснить, ибо во внктрях небыло необходимости копаться. Все и так отлично работает.
А вы unit-tests сделайте на модель + UI. Придется и во внутренности вникать (тесты после перехода на 7-ку отвалились).
M>> * Я не понял, как в application что-нибудь нормально заинжектить (глобальный на все приложение объект/коннектор/пул и т.п.). В сервлетах я это могу из startup listener поднять (вместе с сервлетами ). Как в vaadin'е — так сразу и не нашел. Если знаете, делитесь информацией. T>Ну это вообще детский сад. Про статик сами найдете где почитать, или подсказать? ))) Хотя у нас на спринге все инжектится, и проблем нет.
Что почитать? О том, что static — workaround и я не могу нормально создавать объекты? Вот почему в сервлетах я могу успешно все поднять в StartupListener и передать без всяких статиков? Вообще все явно, для сервлетов, фильтров и всего остального. А для vaadin'а мне приходится изобретать что-то...
M>> * Я не разбирался, что там с security. Можно ли какой-нибудь запрос куда-нибудь подменить. И как оно с текущим Application связано. T>Серверный же фреймворк. Вместе со Spring Security проблем никаких.
А при чем здесь spring security? Или вы с его помощью фильтруете vaadin'овские запросы, которые идут на один адрес? Меня интересует request forgery, который потом переведет "серверное состояние" туда, куда обычными кнопочками данный пользователь не докликал бы. Как против "ручных запросов" поможет spring security, а очень плохо представляю. Возможно, что в vaadin все хорошо, но анализировать его протокол как-то не круто. Обычный ajax анализировать проще.
M>> * Challenge/response authentication не так просто изобразить. Нужно кастомный клиентский компонент писать. Брать challenge/response или пересылать пароль по http(s) — другой вопрос. T>Опять же, поясните, что именно у вас не получилось?
Компонент лень писать. И еще как-то с ваадином дружить. А "из коробки" он этого не поддерживает. Кстати, не совсем понятно, как при этом взаимодействовать со штаными компонентами (полем ввода логина и пароля). Был бы Ajax, я бы элементарно все сделал (там никаких компонент особых не нужно, да и протокол элементарный). А тут чуть ли не поля ввода придется писать и свой обмен. Да, логин и пароль принципиально на сервер передавать не нужно, в этом и бонус challenge/response.
M>> * Что-нибудь глобальное на клиенте прикрутить к сети — то еще приключение (в GWT, впрочем, тоже). Хотелось бы какое-нибудь банальное окно "а у вас связи нет" выводить с возможностью повторить запрос, например. T>Да, это тоже засада. Вроде как в 7-й версии можно перехватить это событие, и как-то обработать. Еще не до конца разобрались.
Архитектура GWT мешает. Там строгая типизация совсем не в том месте прикручена, где надо бы было
T>Так же в 7-й версии теперь можно писать клиентские приложения без сервера, возможно в этом направлении и надо покопать.
А зачем мне чистый client side? Я JS возьму. Или, если очень не хочется заморачиваться с layout и т.п., flash. У меня под flash необходимый набор компонентов есть с реактивными трансформерами (на Java это принципиально не делается).
M>> * Касательно аутентификации. Single-page application не дает сделать более менее безопасную галочку "save password". Нет, я понимаю, что это сразу небезопасно. Но хотя бы по сети этот токен не гонять на каждый запрос, а только при входе (банальный workflow: request -> redirect <...>/auth -> redirect application). Кука с долгоиграющим токеном дается только на <...>/auth и не светится в каждом обмене. T>Это уже не актуально. 7-я версия уже не Single-page application.
Я, конечно, извиняюсь, но там два банальных HTTP redirect, которые о ваадине ни слухом, ни духом (и от пользователя в этом процессе ничего не требуется). При этом еще и на два разных URL'а. В vaadin'е диспетчеризацию, фильтрацию и перенаправление можно, наверное, сделать. Но я предпочитаю это делать прямо — обычным сервлетом с диспетчеризацией.
Здравствуйте, maxkar, Вы писали:
M>>> * Фильтрация на клиенте списка через сервер (банальная фильтр по подстроке, сокращает выбор из списка) T>>Ну так это нормально. Vaadin серверный фреймворк. Никаких проблем с этим не наблюдается. M>Визуально тормозит. Вот я вижу и мне неприятно. А на javascript не тормозит.
У нас клиенты, на планшетах через GPRS работают, и их все устраивает. Я этих тормозов не замечаю, более 500 клиентов использующих ваадин, тоже.
Ну и остальные придирки по списку такие же...
В общем я вас понял.
Вам нужна клиентская технология, вы пишете ее в JS. Попробовали серверный vaadin, и написали как все там плохо.
Только один вопрос, вы в курсе, что разные технологии для разного предназначены и имеют разный порог вхождения?
Может все таки попробуете гвозди забивать, шурупы закручивать, а не наоборот?
Если вам так нужен клиентский код, да ради бога, пишите в своем JS.
Говорить, что трактор проблемный транспорт, я на нем по трассе смог разогнаться до 200км/ч это как странно.
Для вас написать компонент для vaadin, это просто неподъемная задача и проще написать свой vaadin на JS с шахматами и поэтессами.
Отладить его под все браузеры, написать все компоненты и т.д. Это ваш выбор.
Если продолжать аналогии, то да, я конечно понимаю, что купить земли во франции, посадить там религиозно верный виноград и получить в итоге свое самое крутое на свете вино, это тоже подход, и он дает на выходе именно то, что хотели. Но вот большинству достаточно придти в ресторан и выпить хорошего, качественного вина.
Писать на JS+еще куча технологий, энтерпайзные проекты, это просто ад. В котором мы варились не один год. Плавали, знаем, спасибо не надо. Куча разных технологий и подходов, толпа даромоедов, очень долгий процесс отладки всего этого барахла.
После перехода на ваадин, я прототип текущей системы сделал за несколько дней. И это "с нуля", т.е. ваадин первый раз открыл.
После него всякие ExtJS и иже с ним, вспоминаем как страшный сон.
Да, для публичных массовых сайтов vaadin мало подходит, это да. Но для своей ниши он просто шикарен и закрывает 99% потребностей.
Здравствуйте, maxkar, Вы писали:
M>Вот как-то так. Это на маленьком простом приложении. Может, еще чего забыл.
Все таки забыл. Первая — мелочь вроде. Вторая для меня важная.
* Что-то там непонятное со взаимодействием валидации и кнопок было. Помоему, мы валидатор в таблицу пытались прикрутить. Из-за модели ваадина, валидация таблицы падала на очередном обмене. А очередной обмен оказывался при нажатии на кнопку. Так как все происходит внутри черного ящика, кнопка все равно срабатывала. Как предотвратить обрабатывание action, я специально не разбирался (дело происходило где-то внутри моделей). Точно подробностей не помню, но вроде бы так было (точно валидация и вроде бы для таблиц)
* Я не видел в ваадине понятия синхронной операции. Да, где-то там в углу крутится throbbler. Но при этом операции пользователя не блокируются. Как результат, если кнопка инициирует что-то долгое (загрузка с удаленного сервера), эту кнопку нажимают несколько раз (кажется, что не кликнул) и действие выполняется несколько раз. Я в своем ajax чесно блокировал экран сразу же и через 0.3 секунды показывал "ждите". Ладно у нас ничего критичного завязано не было, в production такого может не быть. А обучать пользователей "спокойно ждать" мне как-то не нравится.
* Есть еще теоретический вопрос про машстабирование. Вроде бы формально ваадин масштабируется на несколько серверов. При этом могут быть долго выполняющиеся задачи (для которых предназначен прогресс-бар). Беглый просмотр документации не сказал ничего по поводу того, какие настройки потребуются в кластере, чтобы прогресс отображался и дальше.
Здравствуйте, tumblerrr, Вы писали:
M>>Визуально тормозит. Вот я вижу и мне неприятно. А на javascript не тормозит. T>У нас клиенты, на планшетах через GPRS работают, и их все устраивает. Я этих тормозов не замечаю, более 500 клиентов использующих ваадин, тоже.
А планшет — другой сценарий . Я вот на клавиатуре набираю вслепую и достаточно быстро. Соответственно, я все время вижу монитор и реакции адаптировались под быструю обратную связь. Поэтому "фильтрация по списку" выглядит так: "ставим фокус на поле ввода, набираем символ, набираем символ, набираем символ, набираем символ, ждем, отфильтровалось!". Эту паузу между "я перестал набирать" и "пришли результаты" я прекрасно ощущаю. На планшетах скорость ввода ниже, экран закрывается частично виртуальной клавиатурой да и сам планшет в среднем работает медленнее, чем PC.
T>В общем я вас понял. T>Вам нужна клиентская технология, вы пишете ее в JS. Попробовали серверный vaadin, и написали как все там плохо.
Мне нужна не клиентская технология. Технологию я как раз могу выбирать под необходимую платформу. Вот в данном случае платформа — приложения, работающие в браузере. Есть ряд физических ограничений, вызванных платформой (асинхронность обмена, возможность задержек, ошибок, разных настроек клиентских приложений (разные шрифты, размеры экрана, зум)). Соответственно, у меня ряд требований к приложению на этой платформе. В основном — возможность корректно работать с нужными ограничениями (ошибками связи, задержками и т.п.). Часть моих претензий к ваадину состоит в том, что он плохо учитывает особенности платформы. И эта причина — первая, по которой я бы его не взял. Вторая — архитектурная. Frameworks — зло, я достаточно легко и быстро нахожу задачи, которые из них выбиваются, а мне нужны. Был бы ваадин распилен на полтора-два десятка библиотек, у него еще какие-то шансы могли бы быть.
Если бы при своих подходах он работал хорошо, он имел бы смысл. Хотя "серверные технологии" вообще по определению плохо работают в веб. Может быть, их можно придумать и довести до нормального состояния, но никому это не нужно.
T>Только один вопрос, вы в курсе, что разные технологии для разного предназначены и имеют разный порог вхождения?
Угу. Но я не уверен, что порог вхождения в vaadin будет ниже, чем аналогичный порог вхождения в javascript + ajax. В html'е не такое и большое API. В UI-библиотечках стандартных — тоже не слишком большое и обычно хорошо разделено на рзаличные модули. В качестве языка можно какой-нибудь tscript взять типизированный. А еще ваадин периодически вызывает дикое удивление (property.setReadOnly, таблицы), что с низким порогом вхождения плохо увязывается.
T>Может все таки попробуете гвозди забивать, шурупы закручивать, а не наоборот?
Пробовал. Ваадин позволяет гвозди только под прямым углом забивать. А мне часто нужно под небольшим наклоном У меня много различных соединений и далеко не все квадратное.
T>Если вам так нужен клиентский код, да ради бога, пишите в своем JS.
Мне без разницы до тех пор, пока учитываются особенности платформы.
T>Говорить, что трактор проблемный транспорт, я на нем по трассе смог разогнаться до 200км/ч это как странно.
Ну если у трактора заявляется, что он предназначен для езды по трассам... А для ниши "простенькие админки" у меня тоже аналоги есть. Там могут банальные странички без ajax вообще быть.
T>Для вас написать компонент для vaadin, это просто неподъемная задача и проще написать свой vaadin на JS с шахматами и поэтессами.
Ну да. Только там не ваадин. У моих компонентов почему-то все гораздо проще и по API, и по взаимодействию. Им не нужно реализовывать методы для всего подряд, включая layout, обмен состояниями и т.п. Но главное даже не это. В отличие от ваадина, у меня гора cut-points, по которым я могу заменять одни компоненты на другие. Могу заменить сетевой транспорт (добавить повторы, ручной load balancing и прочее). Могут реализацию некоторых компонентов заменить. И т.п. А в ваадине это все гвоздями прибито с двух сторон. Ну да, мне приходится на новый проект вытаскивать пачку библиотек и допиливать шаблонный конфиг до нужного проекта. Небольшая плата за гибкость.
T>Отладить его под все браузеры, написать все компоненты и т.д. Это ваш выбор.
А в случае ваадиновского компонента разве не так? Его не нужно отлаживать под все браузеры? А еще ваадин дает дополнительные ограничения (нужно уложиться в его протокол, а протокол только через setAttribute и я не могу передать произвольную фигню). А еще нельзя повторно использовать части его клиентских компонентов. Нет уж, лучше я ограничу набор поддерживаемых браузеров (внутренний продукт же!) и отлажусь под них.
T>Если продолжать аналогии, то да, я конечно понимаю, что купить земли во франции, посадить там религиозно верный виноград и получить в итоге свое самое крутое на свете вино, это тоже подход, и он дает на выходе именно то, что хотели. Но вот большинству достаточно придти в ресторан и выпить хорошего, качественного вина.
Да нет, меня хорошее вино устраивает. Но планка достаточно высокая, конечно. На улице и в ларьках такого не продают. И даже на "техническое" вино (добавляется в процессе готовки) далеко не все пойдет.
T>Писать на JS+еще куча технологий, энтерпайзные проекты, это просто ад. В котором мы варились не один год. Плавали, знаем, спасибо не надо. Куча разных технологий и подходов, толпа даромоедов, очень долгий процесс отладки всего этого барахла.
Угу. Было отсутствие архитекторов и политической воли рулить зоопраком технологий. Пришел vendor lock-in и жуткая негибкость, которая и поборола этот зоопарк. Вероятно, теперь у вас одна технология не потому, что ваадин крут и решает все проблемы. А только потому, что ничего другого прикрутить уже не получается Хотя да, какое-никакое, а решение.
T>После перехода на ваадин, я прототип текущей системы сделал за несколько дней. И это "с нуля", т.е. ваадин первый раз открыл. T>После него всякие ExtJS и иже с ним, вспоминаем как страшный сон.
А кто такое ExtJS? Что-то большое и компонентное? Не взлетит подобное в web. Вот не взлетит и все. Нужно что-то гораздо более легковесное. Layouts можно взять в общем виде из GWT и т.п. и перенести их в API (создавать будут DIV'ы). А вот для компонентов ничего глобального не нужно. Тот же button от div'а не сильно отличается — дополнительным обработчиком, обычно.
T>Да, для публичных массовых сайтов vaadin мало подходит, это да. Но для своей ниши он просто шикарен и закрывает 99% потребностей.
А ниша какая? И почему они о ней на своей главной странице не пишут. Вот сейчас вижу: "Vaadin is a Java framework for building modern web applications that look great, perform well and make you and you users happy." По выделенным пунктам он у меня не прошел. Кстати, это все ручками набирать пришлось. Копирование он почему-то не поддерживает. И не понятно, с чем конкурировать. JSP/JSF тот же его конкуренты или нет? Только не говорите про сервер/клиент сайд. Нужно говорить про приложения в браузере.
Итого, ваш подход для ынтырпрайза, это брать html+JS и делать все максимально легким и таким каким надо.
Т.е. на каждый чих писать сервлет, формировать JSON-ы, при изменениях модели все по новой, вносим изменения в сервлет, переписываем клиент, точить свой клиент под разные браузеры и т.д. и т.п.
А сколько по вашему займет времени, прежде чем велик поедет?
Вот взять с нуля и начать это делать? И сколько народу понадобится для боле менее разумных сроков?
Через сколько месяцев появятся боле менее рабочие компоненты вроде гридов?
Как у этого решения будет с безопасностью?
Здравствуйте, insighter, Вы писали:
I>да single page applicaiton,но каждое действие, каждый клик вроде бы обрабатывается на сервере, маленьким ajax запросом, даже если это просто изменение ui. Т.е. другая концепция нежели чем gwt и т.д.
Здравствуйте, tumblerrr, Вы писали:
T>Итого, ваш подход для ынтырпрайза, это брать html+JS и делать все максимально легким и таким каким надо.
Про легкость я ничего не говорил. Делать максимально гибким в нужных местах. Как минимум — обработка типичного транспорта. Я же не виноват, что на клиенте "строго типизированный" транспорт получается гораздо хуже, чем "универсальный на JS". Причем прямо в этом транспорте я даже "неожиданные" логические ошибки могу отслеживать (т.е. по протоколу логической ошибки на какой-то запрос не должно быть, а она есть). Что характерно, клиентский транспорт трогать не нужно при изменении протокола. В зависимости от извращенности пожеланий, может быть, в некоторых случаях нужно будет одну строчку добавить в "конфиг" для получения высокоуровневого сервиса.
T>Т.е. на каждый чих писать сервлет, формировать JSON-ы, при изменениях модели все по новой, вносим изменения в сервлет, переписываем клиент, точить свой клиент под разные браузеры и т.д. и т.п.
Не такая уж и большая работа "писать сервлет" — это один метод в уже существующий "сборник простых сервлетов" или новый класс (для замыкания на параметры) ну и еще одна (одна!) строчка для прикручивания сервлета в нужном месте биндингов. При небольших изменениях ничего в клиенте переписывать не нужно. Нужно только изменения обработать. А при больших изменениях никакой разницы нет. У вас тоже модель данных и UI придется переписывать.
И еще один замечательный момент. Я JSON по идеологическим причинам собираю вручную всегда (хотя в редких случаях можно было бы автоматически). Фокус в том, что далеко не все нужные данные ложатся 1 к 1 на запросы к базе данных. Например, ответ клиенту может собираться из двух-трех разных запросов. Да и при желании я могу строить фрагменты JSON сразу из результатов базы, а не городить DTO. Кстати, о DTO. Для сервера взята scala. Поэтому "DTO" зовется примерно так: case class SomeDTO(field1: String, field2 : Int, field3: Boolean). Парсится так: SomeDTO(rs.field1, rs.field2, rs.field3). Иногда ходят туплы, потому что DTO лишние писать лень. Так что как бы небольшая проблема.
Да, запросы принципиально не ложатся на "простую" схему данных в базе. Usecases — это не просто редактирование данных в справочнике. Так что основная задача — написать правильные запросы для базы, а остальное — мелочи и достаточно легко автоматизируется. Я даже JSON-фрагменты при желании могу с использованием метаданных базы генерировать, так что изменения будут в запросе и на клиенте, без правки java beans.
Касательно "точить под разные браузеры". Под них точится очень небольшая часть библиотек (ui, low-level network transport). Все остальное точить не надо, оно достаточно высокоуровневое и нормально работает через обертки/интеграционный слой.
T>А сколько по вашему займет времени, прежде чем велик поедет?
Какой? Зависит от того, чего в него пихать. Я без опыта html и js (только AS3, там API все же другое) поднимал прототип приложения (полноценного, с базой, клиентом и т.п.) за месяц. Притом с относительно сложной логикой отображения в некоторых местах (добавление/удаление элементов в список, редактирование зависимостей между этими элементами). И при этом я в очередной раз сделал и адаптировал библиотеку реактивного программирования (это день максимум, изначально дня два-три было и еще немного на доделку по ходу). А еще я написал аналог require.js под свои нужды (не понравился мне таймер в его дебрях, да и модули по-другому немного у меня паковались и готовились). Написал layer manager + некоторый focus manager (чтобы модальность реализовывать). Отрефакторить их смог, сделал нормальное разбиение на модули. Это все при том, что я до этого детально ни версткой, ни html не занимался (т.е. справка по css + html). Ну и логика, естественно (в том числе — реаутентификация запросов тех же). При этом я еще на что-то отвлекался... Прототип он только в том, что я не художник. Был бы у меня под рукой художник (верстальщик, конечно, лучше), было бы полноценное приложение.
T>Вот взять с нуля и начать это делать? И сколько народу понадобится для боле менее разумных сроков?
Если с нуля — через месяц велосипед будет прекрасно и резво ездить. Два-три человека достаточно. Я и художник-верстальщик. Если брать готовые компоненты (с предыдущих проектов), через 1-3 дня заведется (нужно аккуратно "стек" пересобрать с учетом конкретных потребностей), стили и то дольше переделывать (если нужно их трогать).
T>Через сколько месяцев появятся боле менее рабочие компоненты вроде гридов?
А что такое грид и зачем он вам вообще нужен? Вы ведь понимаете, что пользователю не нужен сам грид? Ему нужно выполнять какую-то задачу, и эту задачу он выполняет с помощью грида (а может, и не с его помощью). В общем виде он у меня уже давно есть в обычных компонентах:
function renderGrid(items) {
return UI.table('my-cool-grid', items.map(renderRow));
}
function renderRow(item) {
return UI.tr('my-cool-grid-row', item.cols.map(function(elt) {return UI.td('my-cool-elt', UI.text(elt))}))
}
function renderRow(item) {
return UI.tr('my-cool-grid-row',
UI.td('first-column', UI.text(item.name)),
UI.td('second-column', UI.img('user-logo', item.imageurl)));
}
Вот вам даже два варианта рендеринга строки. Чем не grid? Со штатными grid'ами проблема в том, что 90% их функциональности мне для нормальной работы не нужны. А то, что нужно, он как раз не реализует и прикрутить это туда очень и очень сложно (см. мой пример про custom completion же). При необходимости рендеринги строк/ячеек (для редактирования) тюнингуются под конкретную архитектуру фрагмента. В универсальный грид я вкладываться не буду до тех пор, пока не пойму, что он действительно универсален и решает хотя бы 80% моих задач (в других местах останется кастомный рендеринг).
T>Как у этого решения будет с безопасностью?
Прекрасно у него будет с безопасностью. Протокол открыт, на сервере состояния минимум (и то привязано к некоторому "auth token" aka session id), так что анализировать безопасность прекрасно можно. Анализировать "черный ящик" ваадина сложнее.
На сервере:
* Все ненужные для пользователя вызовы API закрыты фильтром. Так что логике не нужно ни о чем заботиться.
* Само приложение тоже почти все закрыто фильтром (открыты только входы для аутентификации).
* Форматом security token, его передачей, сроком хранения рулю я сам. Я вот могу его по secure random сгенерировать, добавить соль, сахар, протереть через SHA-1 и отдать пользователю. Поэтому "подобрать" session-id, например, не получится. А еще я могу ограничить адреса, на которые кука ходит. А могу не кукой передавать, а в запрос дописывать (goodbye CSRF!, кстати, посмотрите на форумах, как там защита от CSRF в vaadin'е включается ). Я даже могу половинку ключа кукой, а половинку — в запросе.
* Я при желании могу json-serializer поменять, например (вдруг там баги обнаружатся, когда он эскейпит не совсем правильно). Изменится в коде очень мало.
На клиенте:
* На security есть небольшой выход на нижнем уровне. Ибо транспорт должен уметь авторизовываться.
* На security есть небольшой выход на "среднем" транспортном уровне и на конфигурации. Там мы пользователя просим пользователя перелогиниться, если в доступе отказано (ну и запрос повторяем).
* И... И все, собственно. Всему остальному нет никакой разницы. Весь обмен и т.п. идет через нижние уровни. При необходимости "permissions" для отображения UI я в запросе передам или на саму страницу.
Так что по user-managed security все хорошо. Остались вопросы защиты сервера (tomcat, jetty, еtc...), но они одинаковы для всех приложений той платформы и разницы между велосипедом и vaadin'ом в этом аспекте нет.
Вообще у вас интересный подход... особенно со scala. Сам активно ее изучаю.
Будет очень большой наглостью попросить демку какую нибудь глянуть?
Ну там простейший проектик, где 1 сущность из 2 полей отображается на странице списком?
Здравствуйте, tumblerrr, Вы писали:
T>Здравствуйте, maxkar, Вы писали:
T>Вообще у вас интересный подход... особенно со scala. Сам активно ее изучаю. T>Будет очень большой наглостью попросить демку какую нибудь глянуть?
Ну... Полностью проект не дам. У него пока непонятный статус. Может быть, потом в opensource выложим, а может и нет. А вот примерчик могу, архив. Два файла полностью новых (серверная и клиентская часть). Еще два — фрагменты из регистрации в клиентской/серверной частях. В клиенте нет сокращений UI.table/UI.tr/UI.td, но они через UI.elt элементарно пишутся (и если будет много таблиц, будут добвалены). Общее представление должны составить. Хэлперы под sql и json писались так, чтобы задачи было удобно реашть. Причем sql периодически дописывается (например, добавляются типы возвращаемых значений и автокастинги). Так что на общую библиотеку sql не потянет, да и интеграция с получением connection в зависимости от проекта/команды может быть разная и синтаксис выборки (select в примере) может быть по-разному организован. css-ку не писал, лень было. Хотя в конфиге подключена, так что если бы кинул в нужное место, все загрузилось бы.
Там запиканы немного packages и пути, все остальное — diff к проекту (в котором и инфраструктура живет).
T>Ну там простейший проектик, где 1 сущность из 2 полей отображается на странице списком?
Пример рабочий был (когда я его тестировал). Там не список, а таблица. Но разница небольшая. Вместо UI.elt('table', ...) и UI.elt('tr', ...) будут UI.div(...). Ну и нужная верстка/стили для элементов могут быть добавлены. Ах да, я еще reload добавил, чтобы показать, как сеть обрабатывается на уровне высокоуровневого API. Последний параметр для Net.post — обработчики логических ошибок (код -> обработчик). Все остальное будет автоматически выведено как ошибка (вроде бы с возможностью повторения, не помню уже), а поддерживаемые коды будут отданы обработчику.
У меня много различных соединений и далеко не все квадратное.
