Здравствуйте, 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'е диспетчеризацию, фильтрацию и перенаправление можно, наверное, сделать. Но я предпочитаю это делать прямо — обычным сервлетом с диспетчеризацией.