JSF против HTML (JSP) для уровня пользовательского интерфейса корпоративных порталов. Какой из них выбрать? и почему?
Недавно моя компания решила перестроить корпоративный портал, который будет использоваться людьми по всему миру, чтобы восстановить там продукт для расширенной гарантии. Они придумали J2EE (spring MVC) и Oracle как технологический стек для уровня Business и решили использовать JSF (java-серверные лица) для разработки интерфейса (User Interface), я есть, будучи Frontend Engineer, захотите добавить JSF, поскольку он даст меньше контроля над сгенерированной разметкой для меня, также JSF будет вводить/генерировать ненужную разметку на страницу, которая будет действовать как нездоровая пища для браузера. Также будет трудно достичь совместимости с браузером, так как я не имею никакого контроля над созданной разметкой. Трудно применить правильное поведение CSS. Также невозможно использовать концепцию, такую как макет жидкости, таблица с меньшими размерами.
Все это приведет к плохому пользовательскому опыту. Моя идея разработана UI с ручной кодировкой HTML, а затем конвертирует эти .html файлы в JSP и подключает эти JSP в архитектуре spring MVC.
Сказав все это, мне нужно представить предложение, которое оправдывает замену JSF на HTML для уровня пользовательского интерфейса, ваши вводы/мысли и предложения будут ценными, пожалуйста, напишите.
Кроме того, я не верю XHTML в качестве другого варианта, он должен быть HTML? Дайте мне знать, что вы думаете и что заставляет вас так думать?
Спасибо, за то, что остановились. Я извиняюсь, если вы читаете все это занимает много времени.
Ответы
Ответ 1
То, что вы заявляете, верно, когда вы используете винтажный JSF 1.0/1.1 API с "чистыми" компонентами JSF. Не было встроенного компонента, с помощью которого вы можете представить элемент HTML <div> (чтобы вы могли выполнить общий макет страницы на семантической основе). Кроме того, вложение "простого" HTML в страницу JSF было больно, потому что оно получилось снаружи и перед деревом компонентов JSF. Вы должны поместить обычный HTML в теги <f:verbatim> по всему месту. Пуристы и неосведомленность менее или менее вынуждены использовать <h:panelGrid> (который делает a <table>) для размещения элементов на странице.
Кроме того, в ранние годы JSF Netbeans поставляется со встроенным визуальным редактором JSF, который позволяет визуально перетаскивать и связывать компоненты JSF без необходимости писать какую-либо строку кода. Это, очевидно, генерирует много на первый взгляд ненужный и неподдающийся памяти код, а точное позиционирование элементов по пикселям было "за кулисами", достигнутое с помощью <h:panelGrid>. Такие приложения JSF с точки зрения ремонтопригодности и веб-семантичности являются полной катастрофой.
Большинство негативных историй, которые вы узнаете о JSF в отношении развития интерфейса, связаны с этим. Большинство пользователей JSF/наблюдателей/ranters с тех пор в настоящее время все еще слепо фокусируются на этом из-за плохого опыта, который у них есть, и/или они считают, что JSF в настоящее время все тот же и/или они видят визуальный редактор как часть JSF в то время как это "просто" другой (плохой) инструмент. Кроме того, большинство из тех, кто говорит, что "JSF отстой", обычно являются теми, кто начал использовать его с помощью редактора visual/drag'n'drop без каких-либо твердых знаний о том, что происходит под капотами (особенно Servlet API!).
Поскольку JSF 1.2 (уже более 4 лет назад выпущен btw), компонент <h:panelGroup> получил дополнительный атрибут: layout="block", который позволит (наконец) отобразить полноценный элемент HTML <div>, чтобы вы могли принесите более семантический макет, используя только компоненты JSF. Но это не только то, что JSF 1.2 также имеет улучшенный обработчик вида, который позволяет встраивать простой HTML в ряд между другими компонентами JSF без сбоев с тегами <f:verbatim>. Вы могли бы легко разместить элементы <div> вокруг, где хотите, не добавляя больше подробностей.
Несмотря на то, что это было существенное улучшение, в стандартной реализации JSF были еще две основные проблемы (но не напрямую связанные с UI): 1) управление состоянием среди запросов затруднено, не захватывая область сеанса (подумайте о сохранении того же данные в таблицах и выпадающих списках и условия, например, атрибута rendered); 2) все проходит через POST, и вы не можете красиво вызывать действия JSFish через GET.
Поскольку JSF 2.0, которому уже почти 1 год, эти проблемы были охвачены новой областью, областью представления и новым набором компонентов для действий GET. Кроме того, JSP заменяется Facelets как технология просмотра по умолчанию. Facelets значительно облегчает создание шаблонов и создание составных компонентов без необходимости использования необработанного кода Java и/или настраиваемых компонентов/рендереров. Несмотря на то, что он основан на XHTML, он может отлично отобразить действительный ответ HTML5 с помощью всего лишь <!DOCTYPE html>. XHTML существует только потому, что Facelets находится под капотом, используя инструмент на основе XML для генерации вывода (X) HTML. Шаблоны на основе XHTML никоим образом не означают, что он может испускать только XHTML/XML.
Все со всеми, проблемы с разметкой не являются проблемой, когда вы используете JSF 1.2 или новее, а также XHTML (Facelets) не должны быть проблемой, поскольку он может отлично отображать действительную разметку HTML5.
Ответ 2
JSF дает вам множество предопределенных, богатых элементов управления, которые предлагают функциональность, в противном случае придется реализовать вручную. Цена за это дает определенную степень контроля за взаимодействием пользователя с приложением и созданием HTML. Он также может стоять на пути интеграции с JS-библиотеками.
Отладка и тестирование значительно проще с JSP и особенно с помощью Spring.
Это действительно зависит от набора функций вашего веб-сайта, навыков команды разработчиков (и группы поддержки), времени для доставки ограничений и т.д.
Я лично предпочитаю более простые технологии, которые дают больше контроля разработчику (JSP с Spring MVC) только для внутренней элегантности фреймворка, но это никогда не определяет фактор....
Ответ 3
Я работал в качестве инженера-интерфейса для Barclays, глобального банка. Теперь я буду первым, кто скажет, что финансовая индустрия имеет долгий путь, когда дело доходит до интерфейса пользователя, и, в частности, Barclays отстает от своих технологий. Тем не менее, они знают, как создавать вещи, которые эффективно и надежно работают, а Leading UI - один из самых удивительных умов, с которыми я когда-либо имел возможность работать. Кроме того, будучи банком, они являются приверженцами соблюдения требований.
Мы использовали именно ту альтернативу, которую вы предложили, и это сработало для нас. Сайты надежно обрабатывали миллионы пользователей ежедневно без каких-либо отрицательных результатов. Работа с пользовательским интерфейсом была простой, и в качестве бонуса, когда приступил к действию Федеральной карты, компания могла нанять базовых веб-пользователей, чтобы войти и выполнить работу cutup/html, которую инженеры могли бы закрепить в системе.
Что касается вашего вопроса XHTML, в конечном итоге мы решили пойти с HTML 4.01 строгим, и вот почему: во-первых, w3 решил не продвигать рабочую группу XHTML... по существу, это на пути к медленной смерти. Во-вторых, 4.01 strict является самым близким к стандарту HTML5 и может быть легко адаптирован, как только поддержка 5 станет более распространенной. Жестким требованием для нас была полная совместимость с IE6, и это позволило нам достичь этой цели.
В ваших переговорах я лично хотел бы утверждать, что важно, чтобы конечный продукт соответствовал текущим веб-стандартам (W3), поскольку это делает его максимально возможным для сайта, который совместим с браузерами (я говорю, что это возможно, Я убежден, что Microsoft найдет способ каким-то образом сломать все, что я создаю в конце концов... это то, как они катятся). Вторичный для вашего сайта может быть проблемой SEO с несоответствующим кодом и препятствиями для доступа, такими как поддержка чтения с экрана. Вы также можете попробовать вывести два похожих (простых) сайта с использованием любой технологии и провести анализ производительности. В случае одного веб-сайта, на котором я работал, это было подано 1 миллион раз в день, сэкономить 5 килобайт в день, переведя на 5 гб данных ежедневно.
Удачи! Это всего лишь одна из многих причин, по которым я ушел от крупных корпоративных заданий с использованием Java и Oracle....
Ответ 4
Я думаю, что компоненты на основе jQuery в сочетании с основанной на действии картой - это путь. Вы получаете полный контроль над страницей, очень мало сюрпризов, быстрое развитие и, в конечном счете, более высокую производительность страницы.
Я создал приложения с компонентами JSF и MS ASPX + DevExpress. В конце концов, я просто хочу больше контролировать то, что заканчивается на моей странице. jQuery очень популярен, поэтому на рынке нет недостатка таланта JS. Ajax почти не вызывает проблем с jQuery.
Кроме того, для создания приложений, основанных на базе данных, в приложениях Java в Java ничего не сравнится со скоростью Tagger Cat. Это может быть старая школа MVC, но она серьезно ориентирована на базу данных и с ней приятно работать.
