JSF по сравнению с HTML (JSP) для уровня UI корпоративных порталов. Какой Выбрать? и ПОЧЕМУ? [закрытый]

10
задан bpeterson76 15 November 2012 в 17:17
поделиться

3 ответа

То, что вы утверждаете, верно, когда вы используете винтажный JSF 1.0 / 1.1 API с «чистыми» компонентами JSF. Не существовало встроенного компонента, с помощью которого можно было бы представить элемент HTML

(чтобы можно было создать общий макет страницы семантическим способом). Кроме того, встраивание «простого» HTML в страницу JSF было проблемой, потому что он рендерился снаружи и раньше дерева компонентов JSF. Вы должны поместить простой HTML в теги повсюду. Пуристы и неосведомленность в меньшей или большей степени вынуждены использовать (который отображает ) для размещения элементов на странице.

Кроме того, на раннем этапе развития JSF Netbeans поставлялся со встроенным визуальным редактором JSF, который позволяет визуально перетаскивать и связывать компоненты JSF без необходимости написания какой-либо строчки кода. Это, очевидно, генерирует много на первый взгляд ненужного и неподдерживаемого кода, а позиционирование элементов с точностью до пикселя было «за кадром» достигнуто с помощью . Такого рода приложения JSF являются полной катастрофой с точки зрения ремонтопригодности и веб-семантики.

Большинство негативных историй, которые вы услышите о JSF в отношении разработки внешнего интерфейса, связано с этим. Большинство пользователей / наблюдателей / участников JSF с тех пор в настоящее время все еще слепо сосредотачиваются на этом из-за плохого опыта, который у них был, и / или они думают, что JSF в настоящее время все тот же, и / или они видят визуальный редактор как часть JSF, в то время как это «просто» еще один (плохой) инструмент.Кроме того, большинство тех, кто говорит, что «JSF отстой», обычно начинают использовать его с визуальным редактором / редактором drag'n'drop, не имея каких-либо основательных знаний о том, что происходит под капотами (особенно Servlet API!).

Начиная с JSF 1.2 (который, кстати, выпущен уже более 4 лет назад), компонент получил дополнительный атрибут: layout = "block" , который позволит он (наконец) отображает полноценный элемент HTML

, чтобы вы могли внести более семантический макет, используя только компоненты JSF. Но не только это, JSF 1.2 также поставляется с улучшенным обработчиком представления, который позволяет встраивать простой HTML в строку среди других компонентов JSF без проблем с тегами . Вы можете красиво разместить элементы
там, где хотите, без дополнительной многословности.

Несмотря на то, что это было серьезное улучшение, все еще оставались две другие серьезные (но не связанные напрямую с пользовательским интерфейсом) проблемы со стандартной реализацией JSF: 1) управление состоянием между запросами затруднено без захвата области сеанса (подумайте о сохранении того же данные в таблицах и раскрывающихся списках и условия, например, визуализированный атрибут ); 2) все проходит через POST, и вы не можете нормально вызывать действия JSFish через GET.

Начиная с JSF 2.0, которому уже почти год, эти проблемы были решены с помощью новой области действия, области представления и нового набора компонентов для действий GET. Кроме того, JSP заменен Facelets в качестве технологии просмотра по умолчанию.Facelets значительно упрощает создание шаблонов и составных компонентов без необходимости прибегать к необработанному Java-коду и / или пользовательским компонентам / средствам визуализации. Несмотря на то, что он основан на XHTML, он может идеально отображать действительный ответ HTML5 с помощью всего лишь . XHTML существует только потому, что Facelets использует инструмент на основе XML для генерации вывода (X) HTML. Шаблоны на основе XHTML никоим образом не подразумевают, что они могут генерировать только XHTML / XML.

В общем, ваши проблемы с разметкой не являются проблемой, когда вы используете JSF 1.2 или новее, а также XHTML (Facelets) не должно быть проблемой, поскольку он может идеально отображать допустимую разметку HTML5.

23
ответ дан 3 December 2019 в 14:17
поделиться

JSF предоставляет вам множество предопределенных, богатых элементов управления, которые предлагают функции, которые в противном случае пришлось бы реализовать вручную. Цена за это заключается в том, чтобы в определенной степени отказаться от контроля над тем, как пользователь взаимодействует с приложением, и над созданным HTML. Он также может препятствовать интеграции с библиотеками JS.

Отладка и тестирование значительно проще с JSP и особенно с Spring.

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

Я лично предпочитаю более простые технологии, которые дают больше контроля разработчику (JSP с Spring MVC) только для внутренней элегантности фреймворка, но это никогда не является решающим фактором ....

6
ответ дан 3 December 2019 в 14:17
поделиться

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

Мы использовали именно ту альтернативу, которую вы предложили, и она нам хорошо сработала. Сайты надежно обслуживали миллионы пользователей ежедневно без каких-либо отрицательных результатов.Работа с пользовательским интерфейсом была простой, и в качестве бонуса, когда появился закон о федеральных картах, компания могла нанять простых веб-специалистов, которые придут и сделают вырезку / HTML-работу, которую инженеры затем могут вставить в систему.

Что касается вашего вопроса XHTML, в конечном итоге мы выбрали строгий HTML 4.01, и вот почему: Во-первых,w3 решила не продвигать рабочую группу XHTML ... по сути, она медленно умирает. Во-вторых, 4.01 strict наиболее близок к стандарту HTML5 и может быть довольно легко адаптирован, когда поддержка 5 станет более широкой. Трудным требованием для нас была полная совместимость с IE6, и это позволило нам достичь этой цели.

В ходе ваших переговоров я бы лично сказал, что жизненно важно, чтобы конечный продукт соответствовал текущим веб-стандартам (W3), потому что это делает наиболее возможным создание сайта, совместимого с существующими браузерами (я говорю, что наиболее вероятно, потому что я ' Я убежден, что Microsoft найдет способ каким-то образом сломать все, что я создаю, в конечном итоге ... это то, как они работают) Вторичными для вашего сайта могут быть проблемы с SEO с несовместимым кодом и препятствиями для доступности, такими как поддержка программ чтения с экрана. Вы также можете попробовать создать два похожих (простых) сайта, используя любую из этих технологий, и провести анализ производительности. В случае с одним веб-сайтом, над которым я работал, который обслуживался 1 миллион раз в день, экономия на размере файла 5 КБ была переведена на 5 ГБ данных в день.

Удачи! Это лишь одна из многих причин, по которым я отказался от большой корпоративной работы, используя Java и Oracle ....

6
ответ дан 3 December 2019 в 14:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: