java уроки - Должен ли я использовать Vaadin Framework




example gwt (17)

Я просто пытался играть с Vaadin Framework, и мне кажется, что он очень прост в использовании. Плюс, что мне нравится в его структуре, так это то, что он построен поверх Google Web Toolkit (GWT) .

Как вы думаете, следует ли продолжать использовать эту структуру или лучше придерживаться GWT?


Answers

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

Как и вы, я наткнулся на этот пост, размышляя о том, какой стек / фрейм использовать для нового проекта. У меня был отличный опыт в Play! (хорошо, в Scala, но это не имеет значения здесь), но убедительные виджеты и их плавная интеграция с серверной стороной + разработка Swing как раз и вызвали мой интерес. Это было в конце 2010 года, и, поскольку ответы убедили меня попробовать Ваадина, я решил вернуться и написать ответ, который мне хотелось бы прочитать здесь, особенно. поскольку этот вопрос по-прежнему актуальен и сегодня. Между тем, Ваадин перешел от версии 6 к 7 с несколькими заметными улучшениями, которые были необходимы, Play! перешел от версии 1 к 2, и я (+ небольшая команда) завершил небольшое количество успешных проектов с обеих сторон.

Я думаю, что сравнение интересно, потому что обе структуры

  1. работать на JVM и может использовать свою богатую экосистему
  2. не могут быть более противоречивыми в их подходах к веб-приложениям и о том, что вы, как разработчик, должны заботиться, и
  3. в меньшей степени, как они относятся к Java EE.

Хвалить

В одном предложении, если вы обнаружите идею переноса настольного приложения в браузер, будучи полностью абстрагированным от основного механизма запроса / ответа HTTP, то Vaadin, вероятно, является вашим кандидатом на создание веб-приложения. Его подход Swing к программированию может быть легким для тех, кто счастлив от низкого уровня HTML и JavaScript. Новый запрос к вашему приложению действительно запускает новый экземпляр, а остальная часть потока зависит от вас и вашей логики. Ссылки возвращаются к старым старым кнопкам для навигации, и вы можете составить свои макеты с помощью множества встроенных шаблонов, не требуя при этом настройки HTML или CSS. API, как правило, довольно согласован и, по общему признанию, хорошо документирован ( книга Ваадина является обязательным чтением. Сделайте это тщательно, так как многие вещи легко доступны, например, связывание ваших компонентов с компонентами и валидаторами ...). Виджеты имеют хорошую общую совместимость между браузерами, что обеспечивает последовательное поведение вашего приложения по широкому кругу клиентов.

Проверка в реальных условиях

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

  1. В 201x году большинство пользователей пользовались большой популярностью в Интернете, и немногие из них практически не используют настольные приложения. Ключевым моментом здесь является то, что браузеры стандартизировали взаимодействие UX с гипертекстовыми ссылками, обратной связью, кнопкой пересылки и перезагрузки, вездесущими вкладками и иногда окнами, а также основной идеей, что большинство действий запускают HTTP-запрос и будут ждать ответа . Это неявный контракт, который веб-сайты придерживаются и вокруг которых они построены. Поэтому мы не должны были удивляться, когда пользователи жаловались, что они не могут использовать кнопки назад / вперед, как они привыкли, или что вкладки не работают ожидаемым образом. И мы согласились. Мы нарушили невидимый контракт, связывающий пользователей и браузеры. Собственно, мы сами неявно не использовали наш браузер с приложением Vaadin так, как мы его использовали с любым другим сайтом. Конечно, вы можете вернуться к вышеупомянутой книге и внимательно прочитать о повторении опыта веб-навигации с фрагментами URL-адресов, и вы увидите, что это на самом деле более активное участие, чем ожидалось, потому что приложения Vaadin являются работоспособными . Более того, парадигмы MVC или MVP накладываются только на разработчика, в отличие от Play! где практически нет другого варианта. Не принимайте это легко, но ваш мозг используется на ярком белом экране, отображаемом на долю секунды после смены страницы. Когда пользователи нажимают и ожидают, что будут взяты новые страницы, браузер подтверждает, показывая песочные часы (или их варианты). С AJAX запросы размещаются за кулисами. Сегодня есть места, где небольшие, почти хирургические удары AJAX стали нормой, но не для крупных обновлений пользовательского интерфейса.

  2. Устные заявления приносят свою долю проблем ... и неприятностей. Балансировка нагрузки (если вы заинтересованы) для одного более сложна. Концепция транзакции совершенно различна, поскольку сеансы Vaadin охватывают многие запросы и поэтому долго контрастируют с основанными на REST подходами, но относительно недолговечны с точки зрения UX. В самом деле, это не редкость для пользователей вернуться к форме, которую они начали несколько часов назад, чтобы закончить свою задачу. Это теоретически может работать и с Ваадином, но вы должны держать сеансы живыми в течение долгого времени, с блокировкой памяти и все время тщательно продумывать это, чтобы масштабировать сторонних пользователей.

    Ссылочные страницы также труднее для пользователей делиться, не говоря уже о закладке (предполагается, что вы имели дело с фрагментами URL-адресов).

  3. Наконец, мы разделяем впечатление, что пользовательский интерфейс, как правило, более вялый, с логикой, находящейся на сервере. Конечно, вы всегда можете создать виджет, загруженный клиентским JavaScript, чтобы обрезать количество раундов, но вам неизбежно придется сделать некоторые обновления пользовательского интерфейса на сервере. JS уже довольно тяжело интерпретировать в моем опыте и делает для меньшего опыта работы на мобильных устройствах (я знаю TouchKit, но все же: приложения HTML5 на мобильных устройствах просто не режут для меня). Кроме того, имейте в виду, что поток пользовательского интерфейса активен после того, как запрос отправлен (т. Е. Действие пользователя на стороне клиента, похожее на вытягивание обновлений пользовательского интерфейса) и будет доступно вам через различные слушатели. Тем не менее, обновление пользовательского интерфейса из фоновых потоков является более сложным (например, нажатие обновлений). Ваадин 7 улучшил ситуацию в этом отношении, особенно с относительно легким HTML-кодом. Значительные улучшения реактивности UI были заметны, просто включив HTTP-сжатие.

Вывод

Поэтому мы остановились и задались вопросом, что мы нашли настолько привлекательным в подходе Ваадин, чтобы начать с этого. Первоначальная разработка была относительно гладкой, давая быстрые результаты, но переработка некоторых концепций для удовлетворения ожиданий в сети UX дала нам сильное впечатление от плавания против прилива. Мы пришли к выводу, что соблазнительная идея абстрагироваться (скрытая?) От механизма запроса / ответа HTTP показала обоюдоострый меч, который раскрыл реальное несоответствие импеданса между веб-приложениями и настольными приложениями.

Вместо того, чтобы притворяться, что веб-страница является еще одним слоем, мы твердо решили, что нужно учитывать, как это работает, и это начинается с использования URL-ориентированного приложения (как наложено Rails / Django / Play). Вы, наверное, слышали, как кто-то сказал, что данные ожидают применения. В настоящее время данные ссылаются на ресурсы URL, поэтому можно с уверенностью сказать, что URL-адреса перехватывают данные. В конце концов, это то, что люди закладывают, не так ли? Таким образом, основное разделение проблем должно также применяться на этом уровне. Вероятно, именно поэтому сеть стала настолько популярной в первую очередь. Поэтому мы пересмотрели наше приложение, чтобы структурировать его больше вокруг центрального контроллера, реагирующего на действия à la Play, сделанные на разных путях ресурсов.

Пока мы поддерживаем наши приложения Vaadin, но из-за некоторых из этих ограничений и фундаментального сдвига парадигмы мы не будем начинать с ним новые проекты. Однако шляпа уходит в команду, которая построила технически согласованную, сплоченную и хорошо документированную веб-инфраструктуру на 360 ° Java, требующую очень мало знания внутренней работы в Интернете. С другой стороны, они даже поддерживают свою структуру с компанией, продающей консалтинговые услуги. Я благодарен за опыт и за то, как он заставил меня переоценить мои взгляды на веб-приложения. Я буду внимательно следить за его эволюцией, но мы определенно нуждаемся в большем контроле и детализации.

Надеюсь, в один прекрасный день Ваадин освободится от всей архитектуры сервлета, на которой он будет иметь свой собственный HTTP-сервер. Еще лучше будет проект MVC, более глубоко внедренный в структуру. Но это маловероятно в обозримом будущем, поскольку, похоже, он нашел прибыльную нишу среди опытных корпоративных Java-горилл, которые только клянутся EE. Сиять на.

TL: DR : Я думаю, что Ваадин не понимает, что такое webapps и что еще важнее, как они должны себя вести. Речь идет о программистах времени, охваченных веб-сайтом и о том, как пользователи взаимодействуют с ним (например, кнопка «Назад», кнопка перезагрузки, вкладки и закладки). Чем ближе веб-приложение привязывается к HTTP-запросам и семантике (глаголам), тем больше вероятность соответствовать ожиданиям пользователей. И это ключ.

EDIT : Если у вас есть опыт Python, я настоятельно рекомендую попробовать Flask, чтобы получить вкус ориентированного на URL-адреса, программирования веб-приложений на основе REST.

РЕДАКТИРОВАНИЕ 2 : Если по какой-либо причине вы чувствуете, что должны использовать полнокадровую структуру, похожую на Vaadin, попробуйте Meteor. Это основанная на JavaScript (как внешняя, так и внешняя) структура, которая работает на Node.js с асинхронной связью, происходящей через WebSocket (таким образом, меньшая латентность, чем запрос / ответ), и по умолчанию она реактивна. Множество вещей, которые мне не нравятся в Ваадине, были рассмотрены в Метеор. Например, логика обновлений пользовательского интерфейса работает на клиенте, что делает его гораздо более отзывчивым, чем в Vaadin. Люди в сообществах JavaScript и Java не очень много пересекаются, но когда я впервые услышал об этом, параллия с Ваадином мгновенно ударила меня. В настоящее время он имеет довольно много импульсов в сообществе по причинам, близким к тем, которые сделали Ваадина популярным, т.е. возможность делать настольные веб-приложения. Попробуйте, если вы также осознали, что Java не слишком сильно относится к изображению будущих веб-приложений, или если вы устали от тех длительных циклов развертывания, когда ударяете об обновлении, это все, что нужно. Но подумайте дважды, прежде чем связывать целое приложение с одной библиотекой.


Для создания привлекательных пользовательских интерфейсов я бы сказал, что это будет путь. Плюс это очень хорошо документировано.


Привет. Как отказ от ответственности, я работаю в компании, разрабатывающей Ваадин.

Vaadin использует GWT таким образом, что у него есть набор компонентов, предварительно скомпилированный в GWT. Вы можете, конечно, дополнительно создать свои собственные компоненты, если захотите. Однако набор компонентов достаточно полный и часто может быть настроен для вашей собственной потребности. Это означает, что вам не нужно перекомпилировать код с Java на JavaScript при каждом изменении вашего приложения. Вы просто объединяете уже имеющиеся компоненты вместе.

Структура управляется сервером, поэтому вся логика обрабатывается на стороне сервера. Компоненты имеют две части: клиентский и серверный. Клиентская сторона - это просто фиктивный «вид» для компонента. После того как вы взаимодействуете с ним, он отправляет на сервер сообщение о том, что то или это было нажато / записано / и т. Д. Затем сервер решает, что нужно сделать. Это для повышения безопасности, потому что вы не можете «взломать» логику, поскольку в javascript доступен только небольшой API, предназначенный для отправки запросов. Это может быть в некоторых случаях небольшим компромиссом со скоростью приложения, но я не думаю, что это так плохо. Худшие удары по скорости - это, как правило, db query round-trip и такие, которые не имеют никакого отношения к выбору структуры пользовательского интерфейса. Вялость демонстраций, как было предложено, может быть вызвана тем, что вы далеки от сервера или на данный момент существует высокий пользовательский удар. Попробуйте в собственной среде, закройте окончательное приложение вашего приложения, чтобы узнать, насколько он хорошо работает. Есть несколько готовых приложений, которые можно просто развернуть для проверки.

Я предполагаю, что выбор сводится к тому, что вы пытаетесь сделать. Vaadin хорош для веб-приложений, так как вы можете создать обычное Java-приложение и легко настроить динамический веб-интерфейс. Если вы делаете что-то более традиционного веб-сайта, где пользователи просматривают только страницу - более активно взаимодействуют с ней, то Ваадин - это не лучший способ пойти. Пойдите с некоторыми другими свободными структурами, такими как rails или php framework и т. Д. Я думаю, что вы больше делаете приложение, поскольку вы предполагаете, что используете GWT сейчас, поэтому Ваадин должен быть хорошим.

Задайте больше вопросов здесь, на форумах Vaadin или на канале irc #vaadin @freenode, и, возможно, кто-то может дать вам больше причин, почему или почему не использовать Vaadin.


В нашей компании, которая является преимущественно крупным хранилищем Java SW (помимо всего прочего), появилась возможность создать новый веб-продукт. Это был набор продуктов, и в трех странах это было много команд. Когда дело дошло до нашей команды, у меня был выбор использования Vaadin для использования нашего опыта разработки java. Я искал Google, чтобы помочь мне в моем решении. Я также прочитал этот пост; Однако я выбрал против Ваадина, хотя многие другие команды выбрали Вадина. Ниже приведены причины из почты, которую я отправляю в это время, прежде чем начать работу с продуктом (до Vaadin или Not). Это из моего личного взгляда, и недоверие к рамкам вообще всегда во мне в разной степени. Так что просто хотел дать еще один вопрос к этому вопросу.

Итак, мы учились изучать HTML, CSS, CSS Selectors, замечательный язык JavaScript и JS libs, JQuery и YUI и своевременно создали веб-продукт с полным графическим интерфейсом и соответствием производительности; и я лично счастлив, и команда так же хорошо, как и пользователи.

Другие команды, которые пошли по пути Ваадина, также создали свои продукты вовремя, и я думаю, что они одинаково счастливы. (Только они не знают радости JavAScript, которой они не хватает :)).

Как сказал кто-то, все абстракции являются непроницаемыми абстракциями, и когда им приходилось мигрировать с Ваадина 6 на Ваадин 7, им приходилось выполнять некоторую переделку, и потребовалось больше времени, чем кто-либо думал; хотя, конечно, им удалось размалывать и обманывать; Тем не менее было немного задержки из-за этого. Также я предполагаю, что была какая-то проблема с аддоном InvientCharts, который не поддерживал Vaadin 7, заставляя команды покупать ($$) соответствующие дополнения к Vaadin Charts и меняться для этого ....

Ваадин или нет

С Vaadin кажется, что базовый JavaScript, HTML и CSS динамически генерируются из приложения типа Java Swing. С предубежденной и, вероятно, глупой точки зрения пуриста, такой «я буду генерировать код для вас» tagline не дает хорошего дизайнерского запаха. Если вам не нужна абстракция, зачем связывать еще одну структуру. Как и в случае любой структуры генерации кода, она должна работать лучше всего для абстракции, которую имел в виду Ваадин, но не очень гибкой; Я чувствую, что, если мы используем веб-технологии, лучше всего использовать инструменты и языки, из которых возникла технология, а именно библиотеки HTML, CSS и JavaScript / JavaScript, а не полагаться на другой уровень абстракции - структуру Vaadin. Это может показаться наивным для опытного разработчика GWT или Vaadin, поскольку, как я полагаю, разработчики Google генерируют наиболее оптимизированный JavaScript, чем ваши закодированные вручную, помогают лучше управлять кодом между несколькими командами и т. Д. (Но в основном при разработке довольно крупных веб-приложений), лучше разработчик производительность, упрощение отладки и т. д. Однако писать компоненты в Java для Vaadin, а затем автоматически конвертировать в JS, я чувствую себя не так, потому что многие из наших разработчиков никогда не узнают очень важный язык программирования - JavaScript для веб-разработки (и быстро набирает скорость в серверная сторона - Node.js). Когда вы полагаетесь на фреймворки, чтобы получить право на JavaScript, тогда вы никогда не преуспеете в этом языке. Я думаю, что для компании, основанной на продуктах, важно научиться из первых рук использовать язык Интернета. Поскольку кто-то прокомментировал, что Java стал похож на COBOL в далеком году, и для компетентности необходимо научиться другим важным языкам, таким как JavaScript. Однако, работая в JS в течение небольшого времени, которое у меня есть, я заметил, что если мы будем кодировать некоторую дисциплину (образец модуля), протестировать всю логику - блок JavaScript - JSTestDriver и запустить JSHint, это довольно мощный язык для работы с , и производительность становится лучше, чем Java, когда она будет изучена. Кроме того, большинство примеров важных компонентов - OpenLayers написаны в JS, и если вам нужно расширить их или работать с оптимальным вариантом, вам нужно знать JavaScript или, если на то пошло, такие мощные библиотеки, как D3.js Итак, коротко, хотя есть много преимуществ в использовании Vaadin и фреймворков, в конечном счете, возможно, использование JavaScript важно?


Я тоже использую Ваадина. Хотя приложение не очень большое, мне очень понравилось, что API был совместим, как правило, хорошо документирован, и, учитывая, что я развиваюсь с помощью нового инструмента, я смог прокрутить материал для очень требовательного клиента в том же самом, или в некоторых случаях, лучшие временные рамки, чем инструменты, которые я использовал раньше.

Очень мало вопросов. Единственный прямо сейчас - клиент настаивает на использовании IE 7 (не спрашивайте), и некоторые из причудливых глазных конфет не работают полностью на 100% в компоненте аддона (диаграмма).

Кстати, я не работаю для Ваадина :-)


Я использую его пару недель, и мне это очень нравится. Код прочный, отлично подходит, очень логичная конструкция, конечные результаты превосходны.

Я люблю его в сочетании с Hibernate, чтобы разобраться во всей базе данных.

Плюс - простота развертывания (с Tomcat вы можете просто загрузить один .WAR-файл через веб-интерфейс, не может быть проще)


Дело в том, что для серьезного развития вы не можете забыть ни о чем, не говоря уже о dtos .. Я являюсь канавкой шва и концепцией серверной стороны ui только потому, что я хочу более тонкого контроля над тем, что происходит на проводе .. Проблема с ваадином для меня это именно то, что имеет состояние на стороне сервера ..


Мы посмотрели на Wicket, где я работаю, но мы нашли вместо 9000 файлов, у нас могло быть более 30 000. У нас почти 1000 экранов с нашим основным приложением для финансовых услуг, и хотя Wicket выглядит великолепно, очень сложно преобразовать наш код Struts 1.3 в Wicket. Наш архитектор выполнил проект POC, и только 3 экрана добавили несколько сотен классов (многие из них предназначены для повторного использования). Также сложно протаивать экран с Wicket, так как ваш html должен соответствовать Java-коду и наоборот.

Ваадин выглядит многообещающим, но это будет трудная продажа команде.

PS Независимо от того, насколько велика рамка, никто не узнает ее, если она не используется в промышленности. Wicket существует уже некоторое время, но очень немногие компании используют его. Большинство разработчиков, с которыми я общаюсь, занимаются изучением новой структуры, которая бесполезна в резюме.

Главное - Vaadin использует Swing-подобный дизайн, и это помогает мне начать с Java с помощью Swing.


Я думал, что Уиккет - это путь вперед, пока я не попытался заставить его работать эффективно и начал депрессию (шутка). Затем я переключился на GWT, который выглядел великолепно, но есть очень много кодовых табличек кодов для написания, а документация не так уж велика ... -> Свет пришел от Ваадина: простой, оперативный, никаких ошибок до сих пор ... !!!


По моему опыту, GWT требует много кода шаблона и замедляется при построении завершенного и богатого пользовательского интерфейса. Обычно мы имеем дело с довольно сложными моделями приложений, которые содержат много устойчивых объектов домена. Чтобы донести все эти данные до клиента, вам необходимо ввести отдельную модель клиента и обеспечить механизм преобразования данных. Мы использовали Dozer для этой цели, и требуется много времени, чтобы отобразить каждую поданную заявку, создать пользовательские преобразователи и протестировать все это.

С другой стороны, если вы не попадете в перестройку, и если приложение не очень сложно, вы можете воспользоваться преимуществами ресурсов клиента и иметь меньшую нагрузку на сервер. Таким образом, вы можете значительно сократить связь с сервером и получить гораздо более гибкое программное обеспечение.

Вадин выглядит очень развитым разработчиком. Но я немного боюсь «массивной атаки AJAX» на сервер. У меня есть опыт работы в ZK, и часто мы сталкиваемся с проблемами производительности, когда тривиальная работа в пользовательском интерфейсе работает медленно, потому что для этого требуется связь с сервером.

Wicket - еще одна хорошая структура, но она больше подходит для веб-сайтов. Он может работать с AJAX и без него, может быть проиндексирован поисковыми системами. И самая привлекательная вещь, которую он имеет дело с чистым HTML-кодом - никаких пользовательских тегов, никаких структур управления, строгого разделения проблем и только специфических нациглов wicketid для компонентов.

Это в основном зависит от ваших потребностей:

  1. Если вам нужно супер быстрое и простое приложение - используйте GWT и используйте ресурсы клиента
  2. Если ваше приложение довольно сложно, чем Vaadin выглядит лучшим вариантом
  3. Если ваше приложение является общедоступным, и вам нужна возможность индексировать его для SEO, чем выбрать Wicket.

Обычные разговоры о Ваадине касаются набора виджета и беспокойства о связи в оба конца между клиентом и сервером.

Но, на мой взгляд, это игнорирует самый значительный (возможно, революционный) аспект Ваадина: он полностью устраняет задачу разработки и реализации клиент-серверной связи, которая обычно требуется для приложений AJAX («A» и «X» в AJAX) ,

С помощью Vaadin вы можете полностью забыть объекты DTO (объекты передачи данных), проблемы безопасности на основе протокола, исключения для лэйзинга загрузки Hibernate и т. Д.

Вы в каком-то смысле просто пишете обычное старое настольное приложение Java Swing, только вы используете другой инструментарий пользовательского интерфейса от Swing.


После почти 1,5-летнего развития не столь огромного приложения GWT, используя все лучшие практики, которые я узнал из последних Google I / O, таких как MVP, EventBus, CommandPattern и т. Д. Я говорю это от всего сердца: чтобы понять, как моя команда и клиент хотели как технически, так и визуально, даже после выхода UiBinder, Ваадин пришел ко мне, как свет в конце туннеля.

После написания почти тысячи шаблонных действий для командного шаблона, еще тысячи докладчиков и просмотров и еще тысяча обработчиков событий и т. Д. Не имея дело с почти 75% этих классов и по-прежнему поддерживая хороший подход к шаблону (дополнение приложения) допустимы небольшие сетевые накладные расходы. С Vaadin, готовым к работе, вы получаете хорошие виджеты, пейджинг, привязку данных, безупречную компоновку. Все это для чего? Некоторое потребление памяти на стороне сервера.

Думаю, я могу сказать, что это приемлемо, потому что я не строю следующий Facebook или что-то в этом роде. Я по-прежнему могу обрабатывать тысячи одновременных пользователей на один средний сервер и, тем не менее, поддерживать задержек с низкой задержкой.

С Vaadin я могу создать приятное приложение с почти половиной строк кода, и все же приложение кажется более полным. :-)

!! ОБНОВЛЕНИЕ 23 февраля 2011 года: я не могу подчеркнуть, как следует понимать ограничения каждой рамки. Ваадин ничем не отличается. Следует помнить, что Ваадин абстрагирует любую форму HTML или JavaScript. Кроме того, полученный HTML очень тяжелый, и вы должны сами позаботиться об изменениях состояния истории. Поэтому, когда вы строите свой проект, имейте в виду эти накладные расходы.


Я пробовал Wicket и Vaadin, и если вы действительно попробуете оба в течение некоторого времени, через месяц вы узнаете, что Ваадин - это путь, а не Wicket, период. - Dheeraj G



Также стоит подумать, что Apache Wicket является сильной альтернативой компонентам Java Web UI, ориентированным на компоненты. Ваадин отлично звучит, и я не хочу умалять эту дискуссию, но выбор - это хорошо. Есть несколько примеров с исходным кодом, связанным с домашней страницей, и еще больше на сайте WicketStuff, а отличная книга от Manning - отличная документация сторонних разработчиков.


Я использовал Ваадина для разработки giftadvisor в компании, в которой я работаю (не Vaadin;).

Vaadin позволяет создавать реальные компонентные веб-приложения Swinglike.

Если вас беспокоит кругооборот клиент-сервер за каждый клик, у меня есть это, чтобы сказать: я создал кнопку мыши, которая меняет внешний вид кнопки на «да», «наводка». Для этого структура должна перейти на сервер и обратно. И он работает достаточно быстро imo. См. http://www.cadeau.nl/sophie чтобы проверить, что я имею в виду.

Мне нравится Vaadin, он удовлетворяет мои потребности и делает веб-развитие легким.

С уважением, Роб.


Ваш код, кажется, не закрывает запись после того, как вы закончите писать. Добавьте out.close() (желательно в блок finally) и он должен работать правильно.





java gwt web-frameworks vaadin