Spring Web Flow и альтернативы

Question

Я создаю веб-приложение с Spring MVC и спящим. Я борюсь с размахом. Например, создание родительского элемента и дочерних элементов на одном интерфейсе требует сброса дочернего компонента после создания первого дочернего элемента. Spring MVC не позволяет удалить компонент из сеанса. В то же время перемещение детей по нескольким областям запросов нецелесообразно. Мне нужна область разговора.

Теперь я рассматриваю Spring Web Flow как решение. Однако он плохо документирован и, судя по всему, полностью зависит от конфигурации xml. Обе эти функции, похоже, предполагают, что это более старый и, возможно, плохо поддерживаемый проект.

Может ли кто-нибудь посоветовать, следует ли мне инвестировать время в изучение Spring Web Flow или, возможно, предложить альтернативные решения, связанные с Spring MVC.

Answer 1

Я потратил некоторое время на это сейчас.

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

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

Собственная документация Webflow невелика, но урок, связанный с here, превосходный.

UPDATE

5 месяцев, и я построил полную систему оценки (то есть тест-система/экзамен). Мой опыт в области ИТ, и у меня есть Ph.d в психологии.

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

Преимущества webflow.

1. Человек может начать тест, сдавайтесь и перезапустить в той же сессии без каких-либо проблем, поскольку flowState заботится обо всем
2. Существует полный контроль, когда пользователь может использовать кнопку назад и как далеко назад пользователь может пойти. Возвращение в состояние после использования незаконного использования подлодки легко и удобно.
3. Характеристики напряженного испытания отличные
4. Конфигурация проста. Я почти не занимался проблемами дизайна или ошибок, связанными с Webflow.
5. FROM - перспективная проекция на более высокий уровень, не было случаев использования, которые требовались с точки зрения бизнеса, которые не могли быть реализованы.

Недостатки

Поскольку все объекты упорядочиваются до их представления на веб-странице, вы должны быть очень осторожны, о том, как вы кэшировать объекты, если вы берете их из бобов flowState.

Answer 2

Spring Web Flow, по-видимому, поддерживается, но не находится в активной разработке. Я вижу a handful of commits, в основном обновляя версии зависимостей и исправляя ошибки.

Вы правы, что конфигурация потока является только XML-документом, который, по моему мнению, является самым большим недостатком этого стареющего проекта Spring. Я искал DSL или динамических сборщиков, и я ничего не нашел.

Сказав это, я бы выстрелил. Возможны простые потоки - даже динамические и унаследованные потоки. Кроме того, форма обратной связи и реализация POST-Redirect-GET Pattern могут быть вам полезны. Этот последний метод предотвращает повторную отправку формы, когда вы используете кнопку возврата к браузеру.

Answer 3

Я смотрел на webflow сам (на прошлый день, ~ 16 часов) с тех пор, как я увидел «правые».

Webflow предлагает различные типы состояний и переходы в эти состояния. Состояния могут иметь отношение, связанное с ним (страница HTML или страница JSP -> входят в нее). Каждая страница JSP - это шаблоны, например PHP, только с использованием java и xhtml. Используя компоненты «прайсы», взаимодействие между клиентом и сервером «кажется» почти автоматизированным (плюс для быстрой разработки). Webflow также предлагает переменные потока, которые представляют собой объект данных Java. Переменная потока может иметь жизнь над потоком и используется представлениями и шаблонами. Webflow позволяет управлять переходами между всеми состояниями.

Однако, я думаю, что именно здесь я прекращаю свое исследование. Во-первых, в чем преимущество веб-потока над хорошим веб-приложением на стороне клиента с использованием AngularJS с Spring MVC (@RequestMapping), если требуется управление потоком, построить его на клиенте. Если вы хотите переменную, которая существует в течение всего времени сеанса, создайте переменную javascript, однако, если переменная должна существовать только на сервере и вы хотите использовать шаблоны, веб-поток кажется идеальным выбором.

Если вам нужен полноценный webapp, то может быть хорошей идеей проверить концепцию типа Spring HATEOAS (передавая состояние как параметр клиенту), и этот параметр относится к ограниченным переменным доступности времени. Меньше кодирования и, похоже, лучше подходит к интернет-модели.