¿Cuáles son las principales desventajas de Java Server Faces 2.0?


234

Ayer vi una presentación sobre Java Server Faces 2.0 que parecía realmente impresionante, aunque actualmente soy un feliz desarrollador de ASP.NET MVC / jQuery. Lo que más me gustó de JSF fue la gran 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 veían muy bien.

Dado que la presentación solo enfatizó las ventajas de JSF, también me gustaría escuchar sobre el otro lado.

Entonces 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?

2
Francamente, deberíamos deshacernos de todo este componente, Bean, "basura" y volver a la codificación normal. No quiero un marco grueso que intente hacer todo por mí (y hacerlo horrible, podría agregar) y distanciarme de lo que realmente está sucediendo debajo. Recomendaría echar un vistazo a TypeScript e intentar encontrar capas muy delgadas de código que funcionen con eso y que estén basadas en eso. JSF / PF y amigos tienen una gran cantidad de "características" pero hay que pasar de puntillas su camino alrededor de ellos y conocer el código o árbol diseño atributo magia derecho a hacer lo que quiera, etc
Andrew

Respuestas:


464

JSF 2.0 desventajas? Honestamente, aparte de la curva de aprendizaje relativamente pronunciada cuando no tienes un conocimiento sólido sobre desarrollo web básico (HTML / CSS / JS, lado del servidor versus lado del cliente, etc.) y la API básica de Java Servlet (solicitud / respuesta / sesión , reenvío / redireccionamiento, etc.), no se me ocurren inconvenientes serios. JSF en su versión actual todavía necesita deshacerse de la imagen negativa que obtuvo durante las primeras edades, durante las cuales hubo varias desventajas serias.

JSF 1.0 (marzo de 2004)

Esta fue la versión inicial. Estaba lleno de errores tanto en el núcleo como en las áreas de rendimiento que no desea conocer. Su aplicación web no siempre funcionó como esperaría intuitivamente. Usted, como desarrollador, huiría llorando.

JSF 1.1 (mayo de 2004)

Esta fue la versión de corrección de errores. El rendimiento aún no ha mejorado mucho. También hubo una gran desventaja: no se puede integrar HTML en la página JSF sin problemas. Todos los HTML simples vanilla se representan antes del árbol de componentes JSF. Debe envolver todo el vainilla simple en <f:verbatim>etiquetas para que se incluyan en el árbol de componentes JSF. Aunque esto fue de acuerdo con la especificación, 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)

Esta fue la primera versión 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 cambio principal fue la mejora del manejo de la vista. Esto no solo separó completamente JSF de JSP, por lo que uno podría usar una tecnología de visualización diferente a JSP, sino que también permitió a los desarrolladores incorporar HTML simple en la página JSF sin problemas con las <f:verbatim>etiquetas. Otro enfoque importante del nuevo equipo fue mejorar el rendimiento. Durante la vida útil de Sun JSF Reference Implementation 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 grave de JSF 1.x (incluido 1.2) es la falta de un alcance entre la solicitud y el alcance de la sesión , el llamado alcance de conversación . Esto obligó a los desarrolladores a molestarse con elementos de entrada ocultos, consultas innecesarias de base de datos 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 acción en el más Aplicaciones web complejas. El dolor podría atenuarse mediante la adopción de una biblioteca de terceros que retiene los datos necesarios en la solicitud posterior, como el componente MyFaces Tomahawk <t:saveState> , el alcance de la conversación JBoss Seam y la Orquesta MyFaces marco de conversación

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 iden la salida HTML generada, especialmente cuando un componente se reutiliza más de una vez en la vista (plantillas, componentes iterativos, etc.) . Debido a que este es un carácter ilegal en los identificadores CSS, necesitaría usar el \para escapar del colon en los selectores CSS, lo que da como resultado 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 CSS? Sin embargo, si no eres un purista, lee también De manera 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 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 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 incorporados de Ajax, el conocido es ICEfaces .

Aproximadamente a la mitad de la vida útil de JSF 1.2, se introdujo una nueva tecnología de vista basada en XML: Facelets . Esto ofreció enormes ventajas por encima de 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 se reemplaza 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 desde JSF2.0 en adelante?

Los poderes Ajax se introdujeron en el sabor del <f:ajax>componente que tiene muchas similitudes con Ajax4jsf. Se introdujeron anotaciones y mejoras en la convención sobre la configuración para eliminar el faces-config.xmlarchivo detallado tanto como sea posible. Además, el carácter separador de ID del contenedor de nombres predeterminado se :volvió configurable, por lo que los puristas de HTML / CSS podrían respirar aliviados. Todo lo que necesita hacer es definirlo como init-paramen web.xmlel nombre javax.faces.SEPARATOR_CHARy la garantía de que no se está utilizando el mismo carácter en cualquier parte del ID de cliente, tales como -.

Por último, pero no menos importante, se introdujo un nuevo alcance, el alcance de la vista . Eliminó otra desventaja importante de JSF 1.x como se describió anteriormente. Simplemente declara el bean @ViewScopedpara habilitar el alcance de la conversación sin molestar a todas las formas de retener los datos en solicitudes posteriores (conversacionales). Un @ViewScopedbean vivirá mientras esté enviando y navegando posteriormente a la misma vista (¡independientemente de la pestaña / ventana abierta del navegador!), Ya sea sincrónica o asincrónicamente (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 obstáculo. La @ViewScopedfalla en los manejadores de etiquetas debido a un problema de huevo de gallina en el ahorro de estado parcial. Esto se corrige en JSF 2.2 y se carga en Mojarra 2.1.18. Tampoco se admite pasar atributos personalizados como HTML5data-xxx . Esto se soluciona en JSF 2.2 por la nueva característica 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<ui:repeat> a veces poco intuitivo de , la nueva implementación de ahorro parcial de estado y el alcance flash mal implementado . La mayoría de ellos están arreglados en una versión 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 de 2013)

Con la introducción de JSF 2.2, HTML5 se utilizó como palabra de moda, aunque 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 más importante de JSF 2.2 es el soporte para atributos de componentes personalizados, abriendo así un mundo de posibilidades, como grupos de botones de radio personalizados sin mesa .

Además 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 solucionado en JSF 2.3), no hay realmente desventajas importantes en la especificación JSF 2.2.

MVC basado en componentes vs MVC basado en solicitud

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 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 requisito principal al considerar un marco MVC, entonces ya no debería estar mirando un marco MVC basado en componentes, sino 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 MVC de solicitud y MVC de componente .

Ver también:


55
En cuanto a los ámbitos: en Java EE 6 también es posible utilizar un ámbito que abarca solicitudes a diferentes vistas. Este es el alcance de la conversación CDI. Aunque técnicamente no es parte de JSF propiamente dicho, se integra tan bien con JSF que se siente como una instalación nativa de JSF.
Arjan Tijms

3
Sin embargo, ui: repeat debe corregirse, y los errores con h: dataTable + ajax anidados en ambas implementaciones son patéticos después de más de un año de lanzamientos. Una pena realmente, porque si no fuera por los dos problemas, recomendaría JSF 2.0 a cualquiera como la solución para todo el desarrollo de aplicaciones web.
fdreger

1
Buena respuesta, pero creo que pierdo algunos argumentos sobre las pruebas. JSF son difíciles de probar. ASP.NET MVC están preparados para TDD.
Guaido79

14
Tengo 20 años de experiencia en JAVA / WEB y rechazo todos los proyectos que usan JSF como yo y, por favor, no se sienta ofendido, siento que JSF es el más horrible de todos los marcos. Viola todas las reglas de abstracción que están mezclando css, html y java. El progreso en los proyectos JSF es ridículo en comparación con, por ejemplo, un proyecto ExtJS con Spring MVC. El mantenimiento en JSF es horrible y simple; de ​​lo contrario, los problemas directos son un completo clusterf *** en JSF. En mi experiencia, NO use JSF. Estándar o no, es un mal estándar que ni siquiera debería ser un estándar. Prueba VAADIM o wicket o ExtJS.
Lawrence

1
La gran desventaja es su integración mediocre en eclipse IDE sin soporte de refactorización, mal soporte de fragmentos de web, mala integración del servidor, no click and go to component or include, ningún gráfico de dependencia de componentes / etiquetas y ningún menú para etiquetas propias o de terceros. Paso mucho tiempo realizando búsquedas en todo el proyecto solo para comprender dónde se usa el componente o la función x.
djmj

56

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

Dos grandes inconvenientes de 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 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 gran 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 está compuesto por los identificadores de sus padres, por ejemplo, form1: button1.
  2. No hay una manera fácil de comentar el fragmento incorrecto de la página. 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 el método isRendered()interno processXxx()antes de continuar.
  4. Incorporar LESS & Sencha es difícil.
  5. No juega bien con REST.
  6. 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 todavía está basado en componentes, y siempre lo será ...

Eche un vistazo a la baja popularidad de Tapestry, Wicket y el bajo entusiasmo de los desarrolladores JSF experimentados (lo que es aún más significativo). Y por el contrario, eche un vistazo al éxito de Rails, Grails, Django, Play! Marco: todos están basados ​​en la acción y no intentan ocultarse de la verdadera solicitud / respuesta del programador y la naturaleza sin estado 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, uso intensivo de formularios), pero para una aplicación web de la vida real no es una buena opción.

Espero que ayude a alguien con sus elecciones con respecto al front-end.


44
+1 web fue diseñado para ser apátrida, bueno o malo, nadie puede cambiarlo (¡y no hay razón para eso!)
Alireza Fattahi

1
Seguramente puede manejar sitios grandes, irctc.co.in está en jsf, el sitio de comercio electrónico más grande de la India. . . pero sí, con JSF no tienes mucho control sobre la IU que se genera.
Nirbhay Mishra

2
¿Podría definir qué es un real-life web application? Además, JSF oculta la naturaleza de la solicitud / respuesta, eso podría ser cierto, pero es responsabilidad de los programadores saber qué está pasando realmente en secreto. Si no sabe cómo funciona HTTP, aprenda antes de JSF o cualquier otro marco.
Xtreme Biker

25

Algunos inconvenientes que me vienen a la mente:

  1. JSF es un marco basado en componentes. Esto tiene restricciones inherentes que tienen que ver con obedecer el modelo componente.
  2. AFAIK JSF solo admite POST, por lo que si desea obtener un GET en algún lugar, debe hacer un servlet / JSP simple.
  3. La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y JavaScript front-end, y muchas veces estas abstracciones son "permeables" y 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 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 que las usan tener poca comprensión de lo que sucede debajo del capó.
  5. Los mecanismos de plantillas que generalmente se usan 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 años convirtiendo.
  6. Cosas como las expresiones EL no se comprueban estáticamente 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 escrito dinámicamente como Ruby o PHP, pero si tengo que soportar la gran hinchazón del ecosistema de Java, exijo escribir para mis plantillas.

Para resumir: el tiempo que ahorrará con JSF, desde evitar escribir el código JSP / servlet / bean repetitivo, lo gastará x10 para escalar y hacer exactamente lo que quiere que haga.


15
Claramente se está refiriendo a JSF 1.xy pasa por alto el hecho de que es un marco MVC basado en componentes mientras tiene en mente un marco MVC basado en solicitudes.
BalusC

17
1) Si no quieres un MVC basado en componentes, ¿por qué estás mirando JSF? 2) Ya no desde JSF 2.0. 3) La parte del dominio es falsa. Ninguno de los componentes JSF hace eso. Los errores de JS en el impl, bueno, ¿hay alguno? Mojarra es bastante maduro a partir de ahora. 4) JSF tiene una curva de aprendizaje empinada, pero eso no lo hace necesariamente malo. 5) Los editores visuales son fallas épicas de todos modos. De nuevo, el MVC basado en componentes frente a MVC es importante. 6) Esa es una cuestión de la herramienta correcta, no de JSF. Eclipse tiene complementos e IntelliJ Ultimate lo hace fuera de la caja.
BalusC

19
@BalusC perdóname si sueno irrespetuoso, pero la pregunta no es JSF 1 vs. JSF 2, y tu respuesta que dice "la historia de JSF" es irrelevante. Además, su afirmación de que JSF "no tiene desventajas serias" no reconoce el principio fundamental de ingeniería de que todas las herramientas tienen sus limitaciones y su dominio donde realizan otras soluciones.
Kay Pale

24
Considero que la historia es muy relevante para aprender cómo JSF 2.0 ha eliminado las viejas desventajas porque fueron exactamente esas desventajas las que le dieron a JSF una imagen negativa en la historia. En cuanto al remanente, bueno, entonces solo tenemos un desacuerdo.
BalusC

55
Sinceramente, no entiendo por qué enumeras "basado en componentes" como una desventaja. Eso es como decir "la desventaja de http es que no tiene estado". Eso debería ser editado. Claro que a veces el hecho de que http no tenga estado es una mierda, pero a veces es exactamente por qué lo usamos. Lo mismo con JSF.
arg20

19

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 debe usar para que pueda hacer un trabajo útil. Considere la asombrosa cantidad de especificaciones y estándares con los que tiene que lidiar para ser realmente competente:

  • HTML en las diversas encarnaciones. No finjas que no necesitas saberlo.
  • HTTP: cuando no puede averiguar qué está sucediendo, debe abrir Firebug y ver. Para eso necesitas saber esto.
  • CSS: me guste o no. No es tan malo realmente y hay algunas buenas herramientas al menos por ahí.
  • XML: JSF probablemente sea el primer lugar donde use espacios de nombres en este grado.
  • Especificación de servlet. Tarde o temprano entrará en métodos de llamada en este paquete. Aparte de eso, debes saber cómo tus Facelets se convierten en XHTML o lo que sea.
  • JSP (principalmente para que sepa por qué no lo necesita en JSF)
  • JSTL (de nuevo, principalmente para hacer frente al marco heredado)
  • 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 trabajo decente al ocultar esto de usted, pero aún necesita saber qué está sucediendo.
  • El DOM Y cómo lo usa un navegador. Ver ECMAScript.
  • Eventos DOM: un tema en sí mismo.
  • Java Persistence Architecture (JPA) que es si desea que su aplicación tenga una base de datos de back-end.
  • Java en sí.
  • JSEE mientras estás en eso.
  • La especificación de inyección de dependencia de contexto (CDI) y cómo choca y se usa 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, es decir, las bibliotecas de componentes y las bibliotecas de proveedores que recogerá en el camino:

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

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

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

Entonces, ¿ESTO ES FÁCIL? Claro, JSF 2.0 es "fácil" siempre que lo único que quiera 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 pegadas como existe hoy en el universo del software. Y no puedo pensar en nada que prefiera usar.


42
La mayor parte de esto también se aplica a cualquier otro marco web. ¿Cómo es culpa de JSF que tengas que conocer jQuery para ser productivo con él?
Adrian Grigore

8
JSF es solo la capa de vista. Ahora parece estar insinuando que con otras tecnologías no necesita saber todo esto, ¿puede mostrarnos cuál?
arg20

Aunque esas tecnologías son de código abierto, están fuertemente vinculadas a las organizaciones privadas que las mantienen. Quizás la palabra propietaria no es adecuada para usted, pero también podría serlo.
AlanObject

Me gustaría ir en defensa de @AlanObject ... Siento que puede haber querido decir al decir propietario, como en el hecho de que todos los proyectos de código abierto, en realidad son "propiedad" de alguien ... Tomemos como ejemplo MySQL. Realmente obtuvieron grandes puntajes cuando se vendieron a Oracle. Como también, lo hizo Java !! Por lo tanto, muchas veces los proyectos de código abierto, a pesar de que están abiertos para ser utilizados / editados / contribuidos, todavía están sujetos a las especificaciones inherentes a cada herramienta de código abierto que está utilizando actualmente. Por ser "propiedad" de alguien. No puede ignorar las especificaciones que son necesarias para usarlas. No es que sea algo malo :)
CA Martin

13
  1. Los desarrolladores sin experiencia generalmente 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 cierta inversión en aprendizaje si desea escribir buenos programas.
  2. Al menos al principio, a menudo te quedarás "atascado" en algún problema y pasarás más tiempo leyendo publicaciones de balusc en Internet que trabajando realmente :) Después de un tiempo será cada vez menos, pero aún puede ser molesto.
  3. Aún más molesto cuando descubres que el problema no se debe a tu falta de conocimiento / error, sino a un error. Mojarra estaba (¿está?) Bastante defectuoso, y otra capa de componentes agrega aún más problemas. Richfaces fue la pieza de software basura más grande jamás escrita :) 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. Entonces diría que tiene errores, pero está mejorando, especialmente después de que la versión 2.2 solucionó algunos problemas con las especificaciones. El framework se está volviendo más maduro pero aún lejos de ser perfecto (¿quizás mi cara sea 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. Una vez más, estoy hablando desde la perspectiva del desarrollador promedio: el que tiene plazos, tutoriales de lectura rápida y búsqueda de stackoverflow 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 que haga lo que desee :) Debe tener cuidado al evaluar si es mejor crear su propio componente o torturarlo. En realidad, si está creando algo realmente único, no recomendaría JSF.

En resumen, mis inconvenientes serían: Complejidad, progreso de desarrollo no muy fluido, defectuoso, inflexible.

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


11

"JSF generará HTML y JavaScript de capa de vista que no puede controlar o cambiar sin entrar en el código del Controlador".

En realidad, JSF le brinda la flexibilidad, puede usar componentes estándar / de terceros o crear uno propio que tenga control total sobre lo que se representa. Es solo un xhtml que necesita para crear sus componentes personalizados con JSF 2.0.


11

No soy un experto en Java Server Faces en absoluto. Pero en mi humilde opinión, la principal desventaja es que es del 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, marcos php y marcos ruby ​​on rails. Me despedí de todos ellos y saludé a Angularjs y TypeScript. Mi capa de presentación se ejecuta en el navegador. No importa si lo sirve Windows IIS con php o ASP.NET, o si lo hace un servidor web Apache que se ejecuta en Linux. Solo necesito aprender un solo marco que funcione en todas partes.

Solo mis dos centavos.


Y no olvide que cada marco del lado del cliente necesita una contraparte aérea para seguridad, validación, etc.
Kukeltje

1
Sí, por supuesto. No solo por seguridad y validación, sino también por el backend y la lógica de negocios. Todo hecho a través de servicios web restfull. El punto aquí es evitar generar html en el lado del servidor.
Jesús López

10

Desarrollamos un proyecto de muestra con JSF (¡Fue una investigación de tres semanas, por lo que podríamos haber perdido algunas cosas!)

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

El proyecto era 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 validación del lado del cliente (para validaciones simples) y validación de base ajax del lado del servidor (para validaciones complejas). Cualquier excepción de servidor (de la capa de servicio) debe mostrarse en la misma página del asistente sin navegar a la página siguiente.

Encontramos eso:

  1. Debe usar algunos hacks de omniFaces para corregir el estado de la vista JSF. El estado JSF se dañará cuando incluya páginas a través de ajax entre sí. Esto parece un error en JSF y puede corregirse en las próximas versiones (no en 2.3).
  2. El flujo JSF no funciona correctamente con ajax (¡o no podríamos hacerlo funcionar!) Intentamos utilizar el componente del asistente Primeface en su lugar, pero la validación del cliente parece no ser compatible y significa que no era un estándar estándar de flujo JSF.
  3. Cuando use algunos componentes de jQuery como jqGird, y necesite cargar resultados JSON, entonces se le recomienda usar servlet puro, el JSF no hará nada por usted. Entonces, si usa este tipo de componentes, su diseño no se ajustará a JSF.
  4. Intentamos hacer algunos scripts de cliente cuando ajax se completa ajaxCompletey descubrimos que el PF 4 ha implementado sus propios eventos ajax. Teníamos algunos componentes jQuery y necesitamos cambiar su código.

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

Resumimos nuestra investigación como:

JSF no funciona bien en un sitio web completamente ajax base.

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 ;-)


6

Para mí, el mayor inconveniente de JSF es el pobre soporte para páginas generadas mediante programación (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á generalmente disponible. Hay muchos puntos en los que tiene que experimentar y el desarrollo es lento y silencioso. Muchas cosas simplemente no funcionan como cabría esperar. Pero generalmente es posible hackearlo de alguna manera.
Lo bueno es que no es un problema en 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 pobre. Si supera el proceso silencioso, complicado y casi indocumentado de la construcción dinámica de componentes compuestos, descubrirá que si anida pocos componentes compuestos un poco más profundo, dejarán de funcionar, arrojando algunas excepciones.

Pero parece que la comunidad JSF es consciente de estas deficiencias. Están trabajando en esto, como 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 especificación.


6

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

  • Si puede usar componentes "listos para usar", supongo que no es terrible.
  • Sin embargo, no funciona bien tan pronto como sales y necesitas interfaces de usuario personalizadas. - Por ejemplo, necesitábamos usar el bootstrap de Twitter para nuestro proyecto. (No imprime en bootstrap).
    • Ahora nuestras páginas funcionan de la siguiente manera:
      • La página se carga.
      • El usuario interactúa con Primefaces que tiene funcionalidad ajax
      • Los enlaces de JavaScript de Bootstrap se rompen
      • Ejecutamos javascript extra para volver a vincular todo

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

Es una pérdida de tiempo, a menos que vuelva a usar cosas "disponibles". También realmente feo (Primefaces) cuando tienes que trabajar con Selenium. Todo se puede hacer, pero de nuevo, 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 aprendiendo jquery / escribiendo HTML directo) o mirando react / angular.


No, su elección de combinar bootstrap y primefaces le hizo escribir más javascript del necesario. Utilice bootfaces o capacidad de respuesta PF. ¿Y cómo es feo trabajar con selenio? Por favor elabora.
Kukeltje

Aquí hay un ejemplo de selenio. Casilla de verificación HTLM: casilla de verificación <input type="checkbox" name="versionsTab" value="version1"> Primefaces: <div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div> Selenium no pudo encontrar la casilla de verificación real que se ha ocultado. p. ej., podría encontrarlo con selectores / codificación / etc. pero el equipo de control de calidad no tan técnico no pudo
rprasad

1
¿Te refieres al nombre concatenado? La belleza está en el ojo del espectador. Si aprende un pequeño xpath, se puede evitar sin muchos problemas. Y esto no es específicamente una cuestión de FP. Y con respecto a las cosas del equipo de diseño. Permítales diseñar la plantilla y, por lo demás, adherirse a las pautas jquery-ui. Funcionó perfectamente para nosotros ...
Kukeltje

Me uní al proyecto más tarde, pero problemas similares a esta presentación donde el proyecto comenzó con bootfaces pero realmente necesitaba bootstrap completo (+ primefaces): oracleus.activeevents.com/2014/connect/…
rprasad

La aplicación funciona: Primefaces no es un obstáculo para el espectáculo de ninguna manera, pero hay (y sigue siendo) un sumidero de tiempo adicional. Por ejemplo, especialmente en comparación con colegas que usan marcos como Play y Django. (De acuerdo con su otro punto, creo que QA debería poder usar xpath si es necesario, les di guiones de trabajo)
rprasad

1

JSF tiene muchas ventajas, la cuestión de estar en desventaja me permite agregar un par de puntos.

En un escenario práctico de implementación de un proyecto web en un marco de tiempo, debe vigilar 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 acomodar la curva de aprendizaje inicial?

  • ¿Tiene suficiente experiencia en su equipo que puede revisar las
    cosas JSF producidas por los desarrolladores?

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


0

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

Hoy en día, los "nuevos" marcos JavaScript simplemente intentan copiar / pegar el modelo basado en componentes "JSF".


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 desarrollada y la tecnología orientada a componentes. Es un poco engorroso e incompleto en comparación con las soluciones proporcionadas por HybridJava.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.