asp.net-mvc jsf jsf-2

asp.net mvc - ¿Cuáles son las principales desventajas de Java Server Faces 2.0?



asp.net-mvc jsf (13)

Ayer vi una presentación en Java Server Faces 2.0 que se veía realmente impresionante, aunque actualmente soy un feliz desarrollador de ASP.NET MVC / jQuery. Lo que más me gustó de JSF fue la enorme cantidad de componentes de interfaz de usuario habilitados para AJAX que parecen hacer que el desarrollo sea mucho más rápido que con ASP.NET MVC, especialmente en sitios pesados ​​de AJAX. Las pruebas de integración también se vieron muy bien.

Ya que la presentación solo enfatizó las ventajas de JSF, me gustaría escuchar acerca del otro lado también.

Así que mis preguntas son:

  • ¿Cuáles son las principales desventajas de Java Server Faces 2.0?
  • ¿Qué podría hacer que un desarrollador de JSF considere usar ASP.NET MVC en lugar de JSF?
  1. Los desarrolladores sin experiencia por lo general crearán aplicaciones que son extremadamente lentas y el código será realmente feo y difícil de mantener. Es engañosamente simple de comenzar, pero en realidad requiere una cierta inversión en aprendizaje si desea escribir buenos programas.
  2. Al menos al principio, a menudo se "atascará" en algún problema y pasará más tiempo leyendo publicaciones de balusc en Internet que trabajando realmente :) Después de un tiempo, cada vez será menos, pero aún así puede ser molesto.
  3. Aún más molesto cuando descubre que el problema no se debe a su falta de conocimiento / error, sino a un error. Mojarra estaba (¿está?) Bastante buggy, y otra capa de componentes agrega aún más problemas. Richfaces fue el software de basura más grande que se haya escrito :) No sé cómo está ahora en la versión 4. Tenemos Primefaces que es mejor, pero aún así se encontrará con errores o falta de características, especialmente con componentes más exóticos. Y ahora tendrá que pagar por las actualizaciones de Primefaces. Así que diría que tiene errores, pero está mejorando, especialmente después de la versión 2.2 que solucionó algunos problemas con las especificaciones. Marco cada vez más maduro pero aún lejos de ser perfecto (quizás myfaces mejor?).
  4. No lo encuentro especialmente flexible. A menudo, si necesita algo muy personalizado y no hay componentes que lo hagan, será un poco doloroso. Nuevamente, estoy hablando desde la perspectiva del desarrollador promedio: el que tiene fechas límite, tutoriales de lectura rápida y búsqueda de cuando se atasca porque no hay tiempo para aprender cómo funciona realmente :) A menudo, algunos componentes parecen tener "casi" lo que necesita, pero no exactamente y, a veces, puede pasar demasiado tiempo para hacer que haga lo que quiere :) Debe ser cuidadoso al evaluar si es mejor crear su propio componente o torturarlo. En realidad, si está creando algo realmente único, no recomendaría JSF.

Entonces, en resumen, mis inconvenientes serían: Complejidad, progreso de desarrollo no muy suave, buggy, inflexible.

Por supuesto, también hay ventajas, pero eso no es lo que pediste. De todos modos, esa es mi experiencia con el marco. Otros pueden tener diferentes opiniones, por lo que la mejor manera es probarlo por un tiempo para ver si es para ti (solo algo más complejo, no ejemplos ingenuos, JSF realmente brilla ahí). JSF es aplicaciones de negocios, como CRMs, etc ...

Algunos inconvenientes que vienen a la mente:

  1. JSF es un marco basado en componentes. Esto tiene restricciones inherentes que tienen que ver con obedecer el modelo de componente.
  2. AFAIK JSF solo admite POST, por lo que si desea obtener un GET en algún lugar, tiene que hacer un servlet simple / JSP.
  3. 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 son "fugaces" y son muy difíciles de depurar.
  4. 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 de 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 utilizan. Tengo poca comprensión de lo que está pasando bajo el capó.
  5. Los mecanismos de plantilla que normalmente se utilizan con JSF no tienen nada que ver con cómo funcionan los desigers web. Los editores WYSIWYG para JSF son primitivos y, en cualquier caso, su diseñador le dará HTML / CSS que tendrá que pasar las edades convirtiendo.
  6. Cosas como las expresiones EL no se verifican de forma estática y tanto el compilador como los IDE no están haciendo un buen trabajo para encontrar errores, por lo que terminará con errores que tendrá que detectar en tiempo de ejecución. Esto podría estar bien para un lenguaje de tipo dinámico como Ruby o PHP, pero si tengo que soportar la gran cantidad de ecosistemas de Java, exijo escribir para mis plantillas.

En resumen: el tiempo que ahorrará con JSF, evitando escribir el código de repetición de JSP / servlet / bean, lo gastará x10 para hacerlo escalar y hacer exactamente lo que quiere que haga.

Comentando en mis últimos meses de experiencia en Primefaces / JSF:

  • Si puedes usar componentes "listos para usar", supongo que no es terrible.
  • Sin embargo, no funciona bien tan pronto como usted sale y necesita interfaces de usuario personalizadas. - Por ejemplo, necesitábamos usar el bootstrap de Twitter para nuestro proyecto. (No primos de arranque).
    • Ahora nuestras páginas funcionan de la siguiente manera:
      • Página de cargas.
      • El usuario interactúa con un Primefaces que tiene funcionalidad ajax
      • Los enlaces de javascript de Bootstrap se rompen
      • Ejecutamos javascript extra para rebindir todo

La promesa de JSF de evitar escribir javascript se convirtió en escribir más javascript del que tendríamos si no usáramos Primefaces, y ese javascript para corregir lo que Primefaces rompe.

Es una pérdida de tiempo, a menos que vuelva a usar cosas "de la estantería". También realmente feo (Primefaces) al tener que trabajar con Selenium. Se puede hacer todo, pero una vez más, solo hay mucho tiempo.

Definitivamente evite esto si está trabajando con un equipo de UX / diseño y necesita iterar rápidamente en la interfaz de usuario (puede ahorrar tiempo al aprender jQuery / escribir HTML directo) o al mirar reaccionar / angular.

Desarrollamos un proyecto de muestra con JSF (fue una investigación de tres semanas, ¡es posible que hayamos perdido algunas cosas!)

Intentamos usar core jsf, si se necesita un componente usamos PrimeFaces.

El proyecto fue un sitio web con navegación. Cada página debe cargarse a través de ajax cuando se hace clic en el menú.

El sitio tiene dos casos de uso:

  1. Una página con una cuadrícula. La cuadrícula se carga a través de ajax y debe admitir clasificación y paginación
  2. Una página de asistente de tres pasos. Cada página tiene la validación del lado del cliente (para validaciones simples) y la validación de la base ajax del lado del servidor (para validaciones complejas). Cualquier excepción del servidor (desde la capa de servicio) debe mostrarse en la misma página del asistente sin navegar a la página siguiente.

Encontramos eso:

  1. Necesita usar algunos hacks de omniFaces para hacer que el estado de la vista JSF sea fijo. El estado JSF se corromperá cuando incluyas páginas a través de ajax entre sí. Esto parece ser un error en JSF y puede solucionarse en las próximas versiones (no en 2.3).
  2. El flujo de JSF no funciona correctamente con ajax (¡o no podríamos hacerlo funcionar!) Intentamos utilizar el componente de asistente de interfaz principal en su lugar, pero la validación del cliente parece no ser compatible y significa que no fue un estándar de flujo JSF estándar.
  3. Cuando use algunos componentes de jQuery como jqGird, y necesita cargar los resultados de JSON, se le recomienda usar el servlet puro, el JSF no hará nada por usted. Por lo tanto, si utiliza este tipo de componentes, su diseño no se ajustará a JSF.
  4. Intentamos hacer algunos scripts de cliente cuando ajax complete con ajaxComplete y encontramos que el PF 4 ha implementado sus propios eventos ajax. Tuvimos algunos componentes de jQuery y necesitamos cambiar su código.

Si cambia la muestra anterior a un proyecto que no sea Ajax (o al menos menos un proyecto ajax) no enfrentará muchos de los problemas anteriores.

Resumimos nuestra investigación como:

JSF no está funcionando bien en un sitio web de base totalmente ajax.

Por supuesto, encontramos muchas características interesantes en JSF que pueden ser muy útiles en algunos proyectos, así que considere las necesidades de su proyecto.

Consulte los documentos técnicos de JSF para revisar las ventajas de JSF, y en mi opinión, la mayor ventaja de JSF es el soporte COMPLETO Y ENORME de @BalusC ;-)

Después de 5 años de trabajar con JSF, creo que puedo agregar mis 2 centavos.

Dos grandes inconvenientes JSF :

  1. Gran curva de aprendizaje. JSF es complejo, eso es cierto.
  2. Su naturaleza componente . El marco basado en componentes intenta ocultar la verdadera naturaleza de la Web, que conlleva 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 enorme error. Desde mi experiencia, cada marco basado en componentes agrega abstracción al desarrollo web, y esa abstracción resulta en una sobrecarga innecesaria y una mayor complejidad.

Y pequeños inconvenientes que me vienen a la mente:

  1. Por defecto, el ID del objeto se compone de los ID de sus padres, por ejemplo, form1: button1.
  2. No hay una manera fácil de comentar el fragmento de la página incorrecta. La etiqueta <ui:remove> necesita contenido sintácticamente correcto que se analiza de todos modos.
  3. Componentes de terceros de baja calidad que, por ejemplo, no comprueban isRendered() dentro del método processXxx() antes de continuar.
  4. Incorporar LESS y Sencha es difícil.
  5. No juega bien con REST.
  6. No es tan fácil para los diseñadores de UX, ya que los componentes listos para usar tienen sus propios estilos CSS, que deben ser sobrescritos.

No me malinterpretes Como un framework de componentes, JSF en la versión 2 es realmente bueno, pero aún está basado en componentes, y siempre será ...

Por favor, eche un vistazo a la baja popularidad de Tapestry, Wicket y el bajo entusiasmo de los experimentados desarrolladores de JSF (lo que es aún más significativo). Y para el contraste, eche un vistazo al éxito de Rails, Grails, Django, Play! Marco: todos están basados ​​en acciones y no intentan esconderse de la verdadera solicitud / respuesta del programador y la naturaleza sin estado de la web.

Para mí es la mayor desventaja de JSF. IMHO JSF puede adaptarse a algún tipo de aplicaciones (intranet, uso intensivo de formularios), pero para aplicaciones web de la vida real no es una buena manera de hacerlo.

Espero que ayude a alguien con sus elecciones en cuanto a front-end.

JSF 2.0 desventajas? 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 de Servlet Java básica (solicitud / respuesta / sesión , reenvío / redireccionamiento, etc.), no se presentan inconvenientes serios. JSF en su versión actual todavía necesita deshacerse de la imagen negativa que obtuvo durante las edades tempranas, durante las cuales hubo varias desventajas graves.

JSF 1.0 (marzo de 2004)

Este fue el lanzamiento inicial. Estaba lleno de errores tanto en las áreas centrales como en las de rendimiento que no quieres conocer. Su aplicación web no siempre funcionó como lo esperaba intuitivamente. Tú, como desarrollador, saldrías corriendo llorando.

JSF 1.1 (mayo de 2004)

Esta fue la versión de corrección de errores. El rendimiento todavía no había mejorado mucho. También había una desventaja importante: no se puede insertar HTML en línea en la página JSF sin problemas. Todo el código HTML de vainilla se procesa antes del árbol de componentes JSF. Debe envolver todas <f:verbatim> etiquetas de vainilla en <f:verbatim> para que se incluyan en el árbol de componentes JSF. Aunque esto fue según la especificación, esto ha recibido muchas críticas. Vea 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 liderado 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. Este JSF no solo se separó completamente de JSP, por lo que se podría usar una tecnología de visualización diferente a la JSP, sino que también permitió a los desarrolladores insertar HTML simple en la página JSF sin tener que usar etiquetas <f:verbatim> . Otro foco importante del nuevo equipo fue mejorar el rendimiento. Durante la vida útil de la Implementación de referencia de Sun JSF 1.2 (que recibió el nombre en código de Mojarra desde la compilación 1.2_08, alrededor de 2008), prácticamente todas las compilaciones se enviaron con mejoras de rendimiento (principales) junto a las correcciones de errores habituales (menores).

La única desventaja seria de JSF 1.x (incluido 1.2) es la falta de un alcance entre la solicitud y el ámbito de la sesión , el llamado ámbito de conversación . Esto obligó a los desarrolladores a tener problemas con elementos de entrada ocultos, consultas de base de datos innecesarias y / o abuso del alcance de la sesión cuando se desea conservar los datos del modelo inicial en la solicitud posterior para procesar con éxito las validaciones, las conversiones, los cambios de modelo y las invocaciones de acción. Aplicaciones web complejas. El dolor se puede suavizar adoptando una biblioteca de terceros que retiene los datos necesarios en la solicitud posterior, como el componente MyFaces Tomahawk <t:saveState> , el ámbito de conversación JBoss Seam y el marco de conversación MyFaces Orchestra .

Otra desventaja para los puristas de HTML / CSS es que JSF utiliza los dos puntos : como carácter separador de ID para garantizar la singularidad del id elemento HTML 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 de CSS, necesitaría usar / para escapar de los dos puntos en los selectores de CSS, resultando en selectores feos y de aspecto extraño como #formId/:fieldId {} o incluso #formId/3A 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 fuera de la caja. No es realmente una desventaja técnica, pero debido a las exageraciones de la Web 2.0 durante ese período, se convirtió en una desventaja funcional. Exadel llegó temprano para presentar Ajax4jsf, que se desarrolló a fondo durante los 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, la conocida como ICEfaces .

Aproximadamente a 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. Jelets es reemplazado por Facelets como la tecnología de vista predeterminada y Facelets se expandió con capacidades para crear componentes personalizados utilizando XML puro (los llamados componentes compuestos ). Consulte también ¿Por qué se prefiere Facelets sobre JSP como lenguaje de definición de vista a partir de JSF2.0?

Los poderes de Ajax se introdujeron en el sabor del componente <f:ajax> que tiene muchas similitudes con Ajax4jsf. Se introdujeron anotaciones y mejoras de convención sobre la configuración para kill el archivo faces-config.xml tanto como sea posible. Además, el carácter separador de ID del contenedor de nombres predeterminado : convirtió en configurable, por lo que los puristas de HTML / CSS podrían respirar aliviados. Todo lo que necesitas hacer es definirlo como init-param en web.xml con el nombre javax.faces.SEPARATOR_CHAR y asegurarte de que no estás usando el personaje en ningún lugar en las ID del cliente, como - .

Por último, pero no menos importante, se introdujo un nuevo ámbito, el ámbito de vista . Se eliminó otra gran desventaja JSF 1.x como se describió anteriormente. Solo declara el bean @ViewScoped para habilitar el alcance de la conversación sin molestar a todas las formas de retener los datos en solicitudes posteriores (conversacionales). Un bean @ViewScoped vivirá siempre que esté posteriormente enviando y navegando a la misma vista (independientemente de la pestaña / ventana del navegador abierta), ya sea de forma síncrona o asíncrona (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 se eliminaron prácticamente todas las desventajas de JSF 1.x, existen errores específicos de JSF 2.0 que pueden convertirse en un éxito de show. El @ViewScoped falla en los manejadores de etiquetas debido a un problema de huevo de gallina en el ahorro de estado parcial. Esto se soluciona en JSF 2.2 y se incluye en Mojarra 2.1.18. Tampoco se admite el paso de atributos personalizados como HTML5 data-xxx . Esto se soluciona en JSF 2.2 mediante la nueva característica de elementos / atributos de paso. Además de 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 de estado parcial y el alcance flash mal implementado . La mayoría de ellos están arreglados en una versión de Mojarra 2.2.x.

Alrededor del tiempo 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 2013)

Con la introducción de JSF 2.2, HTML5 se usó como una palabra de moda, aunque técnicamente solo se admitía en 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 más importante de JSF 2.2 es la compatibilidad con atributos de componentes personalizados, lo que abre un mundo de posibilidades, como los grupos de botones de radio sin tableros personalizados .

Aparte de los errores específicos de la implementación y algunas "pequeñas cosas molestas", como la incapacidad de inyectar un EJB en un validador / convertidor (ya corregido en JSF 2.3), no hay realmente desventajas importantes en la especificación JSF 2.2.

Componente basado en MVC vs Solicitud basada en MVC

Algunos pueden optar por que la principal desventaja de JSF es que permite muy poco control preciso sobre el HTML / CSS / JS generado. Eso no es propio de JSF, solo porque es un marco MVC basado en componentes , no un marco MVC basado en solicitud (acción) . Si un alto grado de control de HTML / CSS / JS es su principal requisito 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 debe tener en cuenta que tendrá que escribir usted mismo todo el texto HTML / CSS / JS. Vea también Diferencia entre Solicitud MVC y Componente MVC .

Ver también:

JSF solo tiene una desventaja: antes de iniciar el desarrollo "JSF", debe comprender claramente el desarrollo web, el núcleo java y la arquitectura de front-end.

En la actualidad, los "nuevos" marcos de JavaScript solo intentan copiar / pegar el modelo basado en componentes "JSF".

JSF tiene muchas ventajas, ya que las preguntas están en desventaja, permítanme agregar un par de puntos.

En un escenario práctico de implementación de un proyecto web con un marco de tiempo, debe estar atento a los siguientes factores.

  • ¿Tiene suficientes miembros senior en su equipo que puedan sugerir los mejores controles adecuados para cada escenario?

  • ¿Tiene el ancho de banda para adaptarse a la curva de aprendizaje inicial?

  • ¿Tiene suficiente experiencia en su equipo que puede revisar el JSF?
    ¿Qué cosas producen los desarrolladores?

Si su respuesta es ''No'' para las preguntas, puede terminar en un código base no mantenible.

No soy un experto en Java Server Faces en absoluto. Pero en mi humilde opinión la principal desventaja es que es el lado del servidor. Estoy cansado de aprender y usar marcos de capas de presentación web del lado del servidor como ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks y ruby ​​on rails frameworks. Me despedí de todos ellos y saludé a Angularjs y TypeScript. Mi capa de presentación se ejecuta en el navegador. No importa si es servido por Windows IIS ejecutando php o ASP.NET, o si es servido por un servidor web Apache que se ejecuta en Linux. Solo necesito aprender un marco que funcione en todas partes.

Sólo mis dos centavos.

Para mí, el mayor defecto de JSF es la falta de soporte para las páginas generadas programáticamente (dinámicamente).
Si desea construir su página (crear un modelo de componente de página) dinámicamente a partir de código java. Por ejemplo, si está trabajando en el constructor de páginas web WYSIWYG. La documentación adecuada de este caso de uso no está disponible en general. Hay muchos puntos en los que hay que experimentar y el desarrollo es lento y lento. Muchas cosas simplemente no funcionan como esperarías. Pero en general es posible hackearlo de alguna manera.
Lo bueno es que no hay problema en la filosofía o arquitectura de JSF. Simplemente no está lo suficientemente elaborado (que yo sepa).

JSF 2 trajo componentes compuestos que deberían facilitar el desarrollo de componentes, pero su soporte para la construcción dinámica (programática) es muy deficiente. Si superas el proceso de construcción dinámica de componentes compuestos, complicado y casi no documentado, descubrirás que si anidas algunos componentes compuestos un poco más profundos, dejan de funcionar, lo que genera algunas excepciones.

Pero parece que la comunidad JSF es consciente de estas deficiencias. Están trabajando en esto como se puede ver en estos dos errores
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

La situación debería ser mejor con JSF 2.2 al menos si estamos hablando de especificaciones.

Para mí, la mayor desventaja de JSF 2.0 es la curva de aprendizaje no solo de JSF, sino también de las bibliotecas de componentes que tiene que usar para lograr que haga un trabajo útil. Considere la asombrosa cantidad de especificaciones y estándares con los que ha tratado para ser realmente competente:

  • HTML en las diversas encarnaciones. No finjas que no necesitas saberlo.
  • HTTP: cuando no puedes entender lo que está pasando, tienes que abrir Firebug y ver. Para eso necesitas saber esto.
  • CSS - Te guste o no. Realmente no es tan malo y al menos hay algunas herramientas bonitas por ahí.
  • XML: JSF será probablemente el primer lugar en el que uses espacios de nombres en este grado.
  • Especificación Servlet. Tarde o temprano entrará en los métodos de llamada de este paquete. Aparte de eso, tienes que saber cómo tus Facelets se convierten en XHTML o lo que sea.
  • JSP (principalmente para saber por qué no lo necesita en JSF)
  • JSTL (una vez más, principalmente para hacer frente a un marco heredado)
  • El lenguaje de expresión (EL) en sus diversas formas.
  • ECMAScript, JavaScript, o como quieras llamarlo.
  • JSON: deberías saber esto incluso si no lo usas.
  • AJAX. Yo diría que JSF 2.0 hace un buen trabajo ocultándote esto, pero aún necesitas saber qué está pasando.
  • El DOM. Y como un navegador lo usa. Ver ECMAScript.
  • Eventos DOM - un tema por sí mismo.
  • Java Persistence Architecture (JPA), es decir, si desea que su aplicación tenga una base de datos de back-end.
  • Java en sí.
  • JSEE mientras estás en ello.
  • La especificación de inyección de dependencia de contexto (CDI) y cómo se choca con y se utiliza con JSF 2.0
  • JQuery: me gustaría verte llevarte bien sin eso.

Ahora, una vez que haya terminado con eso, puede continuar con las especificaciones de propiedad, a saber, las bibliotecas de componentes y las bibliotecas de proveedores que recogerá en el camino:

  • PrimeFaces (mi biblioteca de componentes de elección)
  • RichFaces
  • MyFaces
  • ICEFaces
  • EclipseLink (mi proveedor JPA)
  • Hibernar
  • Soldar

¡Y no te olvides del contenedor! Y todos esos archivos de configuración:

  • GlassFish (2, 3, etc)
  • JBoss
  • Gato

Entonces, ¿ESTO LO HACE FÁCIL? Claro, JSF 2.0 es "fácil" siempre que lo único que quieras hacer sean las páginas web más básicas con las interacciones más simples.

En pocas palabras, JSF 2.0 es la mezcla más complicada y engorrosa de tecnologías encoladas como existe en el universo del software actual. Y no puedo pensar en nada de lo que preferiría usar.

"JSF generará código HTML y JavaScript de la capa de vista que no puede controlar o cambiar sin ingresar al código del controlador".

En realidad, JSF le brinda la flexibilidad, puede usar componentes estándar / de terceros o crear los suyos, lo que tiene control total sobre lo que se procesa. Solo necesita un xhtml para crear sus componentes personalizados con JSF 2.0.

Entre todos los marcos "principales" como Spring MVC, Wicket, Tapestry, etc., el JSF de Java EE con sus componentes compuestos es la capa de presentación más elaborada y la tecnología orientada a componentes. Es un poco engorroso e incompleto en comparación con las soluciones provistas por HybridJava.