Лучший каркас для простого пользовательского интерфейса с несколькими конфигурациями

Question

Я хочу сделать выбор (основанный на Java) каркас для разработки пользовательского интерфейса со следующими ограничениями:

1. Приложение требует очень простого пользовательского интерфейса (форма с 1 или 2 кнопками приводит к списку изображений, текстов и т. Д.), Но фактические типы отображаемых элементов пользовательского интерфейса многочисленны.
2. У нас уже есть логика бэкэнда (в форме веб-сервиса), реализованная так, как мы этого хотим.
3. Важна компонентизация
4. Мы хотели бы иметь точки расширения (в будущем), которые позволят внешним разработчикам изменять внешний вид пользовательского интерфейса без необходимости создавать, компилировать и размещать все приложение или даже весь интерфейс.
5. Производительность и масштабируемость уровня пользовательского интерфейса важны, но мы не ожидаем 100 т / с на машину, а бэкенд, скорее всего, станет узким местом в любом случае
6. Простота обслуживания имеет решающее значение
7. Поддержка легкой интернационализации
8. (и это немного уникально) мы можем захотеть, чтобы некоторые компоненты пользовательского интерфейса отображались по-разному в зависимости от возможностей браузера, версии браузера и т. Д. Однако мы хотим скрыть этот факт от разработчиков, которые создают какой-либо конкретный экран (если это касается насколько это возможно).

Пока что мы выбираем Tapestry и JSF (возможно, с Facelets). Я читал прошлые обсуждения здесь, такие как Лучшая платформа веб-приложений для Java? , но они, кажется, не касаются моих конкретных моментов. Любой совет?

Answer 1

IMO, Stripes также является приемлемым вариантом. Stripes - это среда представления для создания веб-приложений с использованием новейших технологий Java. Так как у вас уже есть весь бэкэнд, как вы упомянули, и вам нужен только UI Framework.

пружина MVC, шов, распорки тут не подходят.

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

Answer 2

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

обновление

"Как это легко изменить?" Я спросил По сути, в JSP есть две вещи, которые облегчают изменение: это богатая платформа, в том смысле, что вы можете написать относительно небольшое количество JSP по сравнению, скажем, с написанием собственных сервлетов и написанием сервлетов для создания стилизованного, согласованного HTML; и, во-вторых, поскольку большая часть JSP больше похожа на шаблонный HTML, чем на код Java, вы можете позволить дизайнерам проигрывать напрямую. Это означает, что все суетливые дизайнерские решения могут быть приняты дизайнерами, вместо того, чтобы заставлять дизайнера делать это, показывать кодировщику, заставлять кодировщика перекодировать его, а затем показывать результаты обратно дизайнеру.

Answer 3

Попробуйте (µ) Micro: http://micro -docs.simplegames.ca / . Это открытый исходный код и код доступен на Github

Дайте мне знать, если у вас есть какие-либо вопросы, я автор.

Answer 4

Попробуйте Wicket. Ты никогда не оглянешься назад!

• Архитектура на основе компонентов.

• Разработка на чистом Java - беспокойство по поводу всего AJAX / Javascript

• Наследование разметки идет рука об руку с наследованием класса - вы привыкли использовать повторно на уровне класса - будьте готовы к повторному использованию на уровне HTML.

• Идеальное разделение интересов. HTML является действительным HTML и поэтому может быть отредактирован в ЛЮБОМ редакторе HTML. Позволяет веб-дизайнерам создавать внешний вид в HTML / CSS, в то время как разработчик следит за кодированием в Java. В отличие от JSP, Java никогда не сможет проникнуть на уровень представления - и это здорово!

Answer 5

Поскольку у вас есть веб-сервисы, GWT и Flex являются жизнеспособными вариантами. Flex, в частности, предназначен для использования веб-сервисов в качестве сервисного уровня.

Answer 6

Мы также рассматриваем Grails на Groovy, хотя я менее знаком с подходом RoR-стиля к веб-разработке. Я также посмотрел на Spring mvc, но я не уверен, что он мне понравился в моем случае использования. Прямое решение на основе jsp, очевидно, является одним из вариантов, но потребует от нас умения, и может привести к уродливому «коду внутри страниц jsp», который не поддерживается, поэтому я не решаюсь делать именно это.