Solución:
¿Desventajas de JSF 2.0? Honestamente, aparte de la curva de aprendizaje relativamente empinada cuando no tiene un conocimiento de fondo sólido sobre desarrollo web básico (HTML / CSS / JS, lado del servidor frente al lado del cliente, etc.) y la API básica de Java Servlet (solicitud / respuesta / sesión , reenvío / redireccionamiento, etc.), no se le ocurren desventajas serias. JSF en su versión actual todavía necesita deshacerse de la imagen negativa que ganó durante las primeras edades, durante las cuales hubo varias desventajas serias.
JSF 1.0 (marzo de 2004)
Este fue el lanzamiento inicial. Estaba lleno de errores en las áreas centrales y de rendimiento que no desea conocer. Su aplicación web no siempre funcionó como esperaba intuitivamente. Tú, como desarrollador, huirías llorando.
JSF 1.1 (mayo de 2004)
Esta fue la versión de corrección de errores. El rendimiento todavía no ha mejorado mucho. También había una gran desventaja: no se puede insertar HTML en la página JSF sin problemas. Todo el HTML simple se renderiza antes de el árbol de componentes JSF. Necesitas envolver toda la vainilla en <f:verbatim> etiquetas para que se incluyan en el árbol de componentes JSF. Aunque esto fue según la especificación, esto ha recibido muchas críticas. Consulte también ao JSF / Facelets: ¿por qué no es una buena idea mezclar JSF / Facelets con etiquetas HTML?
JSF 1.2 (mayo de 2006)
Este fue el primer lanzamiento del nuevo equipo de desarrollo de JSF dirigido por Ryan Lubke. El nuevo equipo hizo un gran trabajo. También hubo cambios en la especificación. El mayor cambio fue la mejora del manejo de la vista. Esto no solo separó completamente JSF de JSP, por lo que se podría usar una tecnología de vista diferente a JSP, sino que también permitió a los desarrolladores insertar HTML vanilla simple en la página JSF sin molestarse con <f:verbatim> etiquetas. Otro enfoque importante del nuevo equipo fue mejorar el rendimiento. Durante la vida de Sun JSF Reference Implementation 1.2 (cuyo nombre en código Mojarra desde la compilación 1.2_08, alrededor de 2008), prácticamente todas las compilaciones se enviaron con mejoras de rendimiento (importantes) junto con las correcciones de errores (menores) habituales.
La única desventaja seria de JSF 1.x (incluido 1.2) es la falta de un alcance entre los solicitud y sesión alcance, el llamado conversacion alcance. Esto obligó a los desarrolladores a lidiar con elementos de entrada ocultos, consultas de base de datos innecesarias y / o abusar del alcance de la sesión cada vez que se desea retener los datos del modelo inicial en la solicitud posterior para procesar con éxito validaciones, conversiones, cambios de modelo e invocaciones de acciones en el más aplicaciones web complejas. El dolor podría suavizarse adoptando una biblioteca de terceros que retiene los datos necesarios en la solicitud posterior como MyFaces Tomahawk <t:saveState> componente, alcance de conversación de JBoss Seam y marco de conversación de MyFaces Orchestra.
Otra desventaja para los puristas de HTML / CSS es que JSF usa los dos puntos : como carácter separador de ID para garantizar la unicidad del elemento HTML id en la salida HTML generada, especialmente cuando un componente se reutiliza más de una vez en la vista (plantillas, iteración de componentes, etc.). Debido a que este es un carácter ilegal en los identificadores CSS, necesitaría usar el para escapar de los dos puntos en los selectores CSS, lo que resulta en selectores feos y de aspecto extraño como #formId:fieldId {} o incluso #formId3A fieldId {}. Consulte también ¿Cómo utilizar el ID de elemento HTML generado por JSF con dos puntos “:” en los selectores de CSS? Sin embargo, si no es un purista, lea también De forma predeterminada, JSF genera identificadores inutilizables, que son incompatibles con la parte css de los estándares web.
Además, JSF 1.x no se envió con las instalaciones de Ajax listas para usar. No es realmente una desventaja técnica, pero debido a la exageración de la Web 2.0 durante ese período, se convirtió en una desventaja funcional. Exadel fue el primero en presentar Ajax4jsf, que se desarrolló a fondo durante años y se convirtió en la parte central de la biblioteca de componentes JBoss RichFaces. También se enviaron otras bibliotecas de componentes con poderes Ajax incorporados, siendo el conocido ICEfaces.
Aproximadamente a la mitad de la vida útil de JSF 1.2, se introdujo una nueva tecnología de visualización basada en XML: Facelets. Esto ofrecía enormes ventajas sobre JSP, especialmente en el área de plantillas.
JSF 2.0 (junio de 2009)
Este fue el segundo lanzamiento importante, con Ajax como palabra de moda. Hubo muchos cambios técnicos y funcionales. JSP es reemplazado por Facelets como la tecnología de vista predeterminada y Facelets se expandió con capacidades para crear componentes personalizados usando XML puro (los llamados componentes compuestos). Consulte también ¿Por qué se prefiere Facelets sobre JSP como lenguaje de definición de vista desde JSF2.0 en adelante?
Los poderes del Ajax se introdujeron en el sabor de la <f:ajax> componente que tiene muchas similitudes con Ajax4jsf. Se introdujeron anotaciones y mejoras de la convención sobre la configuración para eliminar la información detallada faces-config.xml archivo tanto como sea posible. Además, el carácter separador de ID de contenedor de nombres predeterminado : se volvió configurable, por lo que los puristas de HTML / CSS pudieron respirar aliviados. Todo lo que necesita hacer es definirlo como init-param en web.xml con el nombre javax.faces.SEPARATOR_CHAR y asegurándose de que no está utilizando el carácter usted mismo en ninguna parte de la identificación del cliente, como -.
Por último, pero no menos importante, se introdujo un nuevo alcance, el vista alcance. Eliminó otra gran desventaja de JSF 1.x como se describió anteriormente. Solo declaras el frijol @ViewScoped para habilitar el alcance de la conversación sin molestar todas las formas de retener los datos en solicitudes posteriores (conversacionales). A @ViewScoped bean vivirá siempre que posteriormente envíe y navegue a la misma vista (¡independientemente de la pestaña / ventana del navegador abierta!), ya sea de forma sincrónica o asincrónica (Ajax). Consulte también Diferencia entre el alcance de vista y solicitud en beans administrados y ¿Cómo elegir el alcance de bean correcto?
Aunque prácticamente se eliminaron todas las desventajas de JSF 1.x, hay errores específicos de JSF 2.0 que podrían convertirse en un éxito. los @ViewScoped falla en los controladores de etiquetas debido a un problema de huevo de gallina en el ahorro parcial del estado. Esto se corrigió en JSF 2.2 y se actualizó en Mojarra 2.1.18. También pasando atributos personalizados como HTML5 data-xxx no es apoyado. Esto se corrige en JSF 2.2 mediante la nueva función de elementos / atributos de paso a través. Además, la implementación de JSF Mojarra tiene su propio conjunto de problemas. Relativamente muchos de ellos están relacionados con el comportamiento a veces poco intuitivo de <ui:repeat>, la nueva implementación de ahorro estatal parcial y el alcance flash implementado de manera deficiente. La mayoría de ellos están arreglados en una versión Mojarra 2.2.x.
Alrededor de la época de JSF 2.0, se introdujo PrimeFaces, basado en jQuery y jQuery UI. Se convirtió en la biblioteca de componentes JSF más popular.
JSF 2.2 (mayo de 2013)
Con la introducción de JSF 2.2, HTML5 se usó como palabra de moda a pesar de que técnicamente solo era compatible con todas las versiones anteriores de JSF. Consulte también JavaServer Faces 2.2 y compatibilidad con HTML5, por qué se sigue utilizando XHTML. La nueva característica JSF 2.2 más importante es la compatibilidad con atributos de componentes personalizados, lo que abre un mundo de posibilidades, como los grupos de botones de opción sin tabla personalizados.
Aparte de los errores específicos de la implementación y algunas “pequeñas cosas molestas” como la imposibilidad de inyectar un EJB en un validador / convertidor (ya corregido en JSF 2.3), no hay desventajas importantes en la especificación JSF 2.2.
MVC basado en componentes vs MVC basado en solicitudes
Algunos pueden optar por que la principal desventaja de JSF es que permite muy poco control detallado sobre el HTML / CSS / JS generado. Eso no es propio de JSF, es solo porque es un basado en componentes Marco MVC, no un solicitud (acción) basada Marco MVC. Si un alto grado de control de HTML / CSS / JS es su requisito principal al considerar un marco MVC, entonces ya no debería estar mirando un marco MVC basado en componentes, sino en un marco MVC basado en solicitudes como Spring MVC. Solo necesita tener en cuenta que tendrá que escribir todo ese HTML / CSS / JS repetitivo usted mismo. Consulte también Diferencia entre Request MVC y Component MVC.
Ver también:
- ¿Cuál es la diferencia entre JSF, Servlet y JSP? (solo para entender lo básico)
- Uso de JSF para desarrollar diseños CSS sin tablas (otro mito sobre JSF)
- JSF vs HTML plano / CSS / JS / jQuery (cuando JSF es la elección incorrecta)
- Patrones de diseño en aplicaciones web (ilustra la ideología detrás de MVC)
Después de 5 años de trabajar con JSF, creo que puedo sumar mis 2 centavos.
Dos mayor JSF inconvenientes:
- Gran curva de aprendizaje. JSF es complejo, eso es cierto.
- Su componente naturaleza. El marco basado en componentes intenta ocultar la verdadera naturaleza de la Web, que viene con una gran cantidad de complicaciones y desastres (como no admitir GET en JSF en casi 5 años).
En mi humilde opinión, ocultar la solicitud / respuesta HTTP del desarrollador es un error enorme. Desde mi experiencia, cada marco basado en componentes agrega abstracción al desarrollo web, y esa abstracción da como resultado una sobrecarga innecesaria y una mayor complejidad.
Y menor inconvenientes que me vienen a la mente:
- Por defecto, el ID del objeto se compone de los ID de sus padres, por ejemplo form1: button1.
- No es una forma fácil de comentar el fragmento de página incorrecto. Etiqueta
<ui:remove>necesita contenido sintácticamente correcto que se analiza de todos modos. - Componentes de terceros de baja calidad que, por ejemplo, no se comprueban
isRendered()dentroprocessXxx()método antes de continuar. - Incorporar LESS & Sencha es difícil.
- No funciona bien con REST.
- No es tan fácil para los diseñadores de UX, porque los componentes listos para usar tienen sus propios estilos CSS, que deben sobrescribirse.
No me malinterpretes. Como marco de componentes, JSF en la versión 2 es realmente bueno, pero aún está basado en componentes, y siempre lo estará …
Por favor, observe la baja popularidad de Tapestry, Wicket y el bajo entusiasmo de los desarrolladores JSF experimentados (lo que es aún más significativo). Y para contrastar, eche un vistazo al éxito de Rails, Grails, Django, Play! Framework: todos están basados en acciones y no intentan esconderse del programador verdadera solicitud / respuesta y naturaleza apátrida de la web.
Para mí, es una gran desventaja de JSF. En mi humilde opinión, JSF puede adaptarse a algún tipo de aplicaciones (intranet, formularios intensivos), pero para la vida real web aplicación no es un buen camino a seguir.
Espero que ayude a alguien con sus elecciones en lo que respecta al front-end.
Algunos inconvenientes que me vienen a la mente:
- JSF es un marco basado en componentes. Esto tiene restricciones inherentes que tienen que ver con obedecer el modelo de componentes.
- AFAIK JSF solo admite POST, por lo que si desea un GET en algún lugar, debe hacer un servlet / JSP simple.
- La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y JavaScript de front-end, y muchas veces estas abstracciones tienen “fugas” y son muy difíciles de depurar.
- Estas abstracciones pueden ser un buen punto de partida para un desarrollador junior o alguien que no se sienta cómodo con un dominio en particular (por ejemplo, JavaScript front-end), pero son muy difíciles de optimizar para el rendimiento, ya que hay varias capas involucradas y la mayoría de las personas las usan. tengo poca comprensión de lo que está sucediendo bajo el capó.
- Los mecanismos de creación de plantillas que se utilizan habitualmente con JSF no tienen nada que ver con el funcionamiento de los diseñadores web. Los editores WYSIWYG para JSF son primitivos y, en cualquier caso, su diseñador le dará HTML / CSS que tendrá que pasar años convirtiendo.
- Cosas como las expresiones EL no se verifican estáticamente y tanto el compilador como los IDE no están haciendo un buen trabajo en la búsqueda de errores, por lo que terminará con errores que tendrá que detectar en tiempo de ejecución. Esto podría estar bien para un lenguaje escrito dinámicamente como Ruby o PHP, pero si tengo que soportar la enorme hinchazón del ecosistema Java, exijo escribir para mis plantillas.
Para resumir: El tiempo que ahorrará con JSF, desde evitar escribir el código repetitivo JSP / servlet / bean, lo gastará x10 para escalar y hacer exactamente lo que quiere que haga.