Здравствуйте, 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). В трезвом уме никогда бы не взял его
> в начальный проект (даже без опыта использования).
>

Спасибо ! Ценные наблюдения.

--
WBR,
Serge.

Здравствуйте, 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 тот же его конкуренты или нет? Только не говорите про сервер/клиент сайд. Нужно говорить про приложения в браузере.

Здравствуйте, maxkar, Вы писали:

Итого, ваш подход для ынтырпрайза, это брать html+JS и делать все максимально легким и таким каким надо.
Т.е. на каждый чих писать сервлет, формировать JSON-ы, при изменениях модели все по новой, вносим изменения в сервлет, переписываем клиент, точить свой клиент под разные браузеры и т.д. и т.п.

А сколько по вашему займет времени, прежде чем велик поедет?
Вот взять с нуля и начать это делать? И сколько народу понадобится для боле менее разумных сроков?
Через сколько месяцев появятся боле менее рабочие компоненты вроде гридов?
Как у этого решения будет с безопасностью?

Здравствуйте, insighter, Вы писали:

I>да single page applicaiton,но каждое действие, каждый клик вроде бы обрабатывается на сервере, маленьким ajax запросом, даже если это просто изменение ui. Т.е. другая концепция нежели чем gwt и т.д.

Т.е. неюзабельные тормоза при плохой связи?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, 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'ом в этом аспекте нет.

Здравствуйте, maxkar, Вы писали:

Вообще у вас интересный подход... особенно со 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 — обработчики логических ошибок (код -> обработчик). Все остальное будет автоматически выведено как ошибка (вроде бы с возможностью повторения, не помню уже), а поддерживаемые коды будут отданы обработчику.