¿Cuál es la necesidad de JSF, cuando la interfaz de usuario se puede lograr con bibliotecas de JavaScript como jQuery y AngularJS?

116

Estaba leyendo sobre JSF que es un marco de interfaz de usuario y proporciona algunos componentes de interfaz de usuario. Pero, ¿cómo es mejor o diferente de la cantidad de componentes que están disponibles en jQueryUI, AngularJS, ExtJS o incluso HTML, CSS y JavaScript sin formato?

¿Por qué debería alguien aprender JSF?

user-interface jsf javascript-framework

— sushil bharwani
fuente

3

ventajas del html generado por el servidor: capacidad de búsqueda en los motores de búsqueda, ocultar vistas según la autorización. de lo contrario, lo hemos abandonado por puro ajax ui.

— Neil McGuigan

5

También abandoné JSF a favor de AngularJS + backend RESTful. (Manzanas y naranjas, pero Angular es tan agradable que no necesito muchos de los beneficios de JSF)

— arg20

JSF es un marco MVC basado en componentes que se construye sobre la API de Servlet y proporciona componentes a través de taglibs que se pueden usar en JSP o en cualquier otra tecnología de vista basada en Java, como Facelets.

— Divyesh Kanzariya

154

JSF a JSP / Servlet / HTML / CSS / JS simple es como jQuery a JS simple: haga más con menos código. Para tomar PrimeFaces (basada en jQuery + jQuery UI) como ejemplo, navegue por su escaparate para ver ejemplos de código completos. BootsFaces ( basado en jQuery + Bootstrap UI) también tiene un escaparate con ejemplos de código completos. Si estudia esos ejemplos de cerca, verá que básicamente necesita una clase Javabean simple como modelo y un archivo XHTML como vista.

Tenga en cuenta que no debería ver JSF como un reemplazo de HTML / CSS / JS solo, también debe tener en cuenta la parte del lado del servidor (específicamente: JSP / Servlet). JSF elimina la necesidad de todo el estándar de recopilar parámetros de solicitud HTTP, convertirlos / validarlos, actualizar los valores del modelo, ejecutar el método Java correcto para hacer las cosas comerciales y generar el código estándar HTML / CSS / JS. Con JSF básicamente terminas con una página XHTML como definición de vista y una clase Javabean como definición de modelo. Esto acelera enormemente el desarrollo.

Al igual que con cada marco MVC web basado en componentes, en JSF tiene un control menos detallado sobre el HTML / CSS / JS renderizado. Agregar código JS personalizado no es tan fácil, ya que también debe tener en cuenta el estado de la vista JSF en el lado del servidor (por ejemplo, habilitar un botón deshabilitado en el lado JS no habilitará el botón en el lado JSF, que a su vez es un gran ventaja de seguridad). Sin embargo, si eso es un gran éxito, entonces busque un marco MVC web basado en acciones como Spring MVC . Solo tendrá en cuenta que debe escribir todo ese código HTML / CSS / JS (¡y prevención contra XSS, CSRF y manipulación DOM!) Usted mismo . Además, si pasa de Facelets a JSP, también perderá las capacidades avanzadas de creación de plantillas.

Por otro lado, si tiene un gran sitio web basado en JSP / Servlet / HTML / CSS / JS / jQuery y desea refactorizar el código repetido JSP / Servlet / HTML / CSS / JS / jQuery en componentes reutilizables, entonces una de las soluciones sería JSF. Las plantillas, los archivos de etiquetas y los componentes personalizados pueden ayudar en esto. En esa perspectiva, JSF está por encima de JSP / Servlet / HTML / CSS / JS / jQuery (y por eso también es muy importante comprender esos conceptos básicos antes de sumergirse en JSF).

Puede encontrar un proyecto basado en JSF de lanzamiento del mundo real aquí: Aplicación Java EE Kickoff . Verás que contiene junto a JSF como buenos HTML5 , CSS3 y jQuery .

Ver también:

— BalusC
fuente

15

¿Hacer más con menos código? Pero con más xml ... qué compensación ... además, te priva de flexibilidad

— Danubian Sailor

33

En JSF 2.0+, xml no es necesario.

— Cagatay Civici

5

Tenemos anotaciones en JSF 2.0

— VdeX

1

Parece que no hay una delimitación clara entre la capa de controlador / negocio y la vista, con JSF, ya que gran parte de la vista se genera en el servidor. Entiendo que todo se compila en el servidor antes de enviarse al navegador, pero prefiero que mi objeto Java devuelva datos que la vista representa, en lugar de enviar datos / lógica de representación.

— Rick

1

Estoy de acuerdo en que JSF es una cosa del lado del servidor con un poderoso control sobre HTML.

— Plain_Dude_Sleeping_Alone

28

JSF se creó para que las tiendas de Java no tuvieran que aprender cosas como jQuery y construir JS complejas, sino que se centraran en una pila puramente Java. En un mundo donde el tiempo es dinero y muchos lugares ya se centran en el desarrollo de Java, un lenguaje / pieza menos en la pila hace que la capacitación y el mantenimiento sean más rápidos y, por lo tanto, más baratos.

Agregaré que JavaScript es fácil de convertir en una pesadilla de mantenimiento en equipos grandes, especialmente si algunos de los desarrolladores del proyecto no son muy expertos en web.

— Andrew White
fuente

Entonces, si me siento bastante cómodo con JQuery JS, etc., ¿no necesito concentrarme en JSF?

— sushil bharwani

2

Todo depende del problema que intentas resolver y con qué equipo lo estás resolviendo.

— Andrew White

1

Estoy de acuerdo con el equipo, pero estoy interesado en aprender qué diferentes problemas puede resolver JSF y js jQuery, etc. Solo intento generar motivación para aprender JSF.

— sushil bharwani

1

Ninguno, solo proporciona una forma diferente de resolver los mismos problemas.

— Andrew White

8

Incluso si se siente realmente cómodo con JQuery, JSF sigue siendo realmente útil. Proporciona una manera fácil de conectar el código del lado del servidor a las representaciones del lado del cliente. Algunos 'componentes compuestos' de Facelets son solo una envoltura bastante delgada alrededor de HTML y JS (incluido JQuery). Son muy fáciles de construir y, en general, facilitan toda la conexión del lado cliente-servidor.

— Arjan Tijms

23

Con Javascript y marcos como jQuery, tiene total flexibilidad y control total. Con ext's, etc., pierde mucho control y debe adaptarse al marco. Con JSF pierde totalmente el control y debe adaptarse totalmente al framework. Se te invoca en ciclos de vida, etc. y finalmente no tienes control sobre cuándo se puede realizar la llamada al servidor y dónde no. Si va a hacer algo considerado "especial", está en una posición muy difícil. Y en el mundo JSF, incluso las cosas básicas como la clasificación de tablas de varias columnas o los campos en los que solo puede escribir un conjunto limitado de caracteres (como el campo numérico) se consideran "especiales".

Sin embargo, cuanta más flexibilidad tenga, más errores o malas prácticas podrá cometer. La alta flexibilidad funciona solo con programadores altamente inteligentes, otros convertirán el proyecto en una pesadilla inmanejable.

Pero, con JSF y su flexibilidad limitada, siempre hay solo unas pocas (o incluso una) forma correcta de hacer algo. Es muy limitado, no puede crear atajos, debe escribir más XML, etc., pero cuando se adapta al estándar, hay un mejor control sobre el código que producirán los programadores inexpertos o poco calificados. Como resultado, las grandes corporaciones aman JSF porque es 'más seguro' para ellas.

Cuando me mudé de GWT a JSF, me sorprendió ver cuántas cosas, que eran naturales para mí, se consideraban muy atípicas y cuántas cosas simples eran tan difíciles de lograr. Además, incluso hacer los cambios más pequeños, como agregar el signo ':' después de la etiqueta, que en la aplicación con tecnología GWT / jQuery cambiaría una etiqueta generadora de función, requirió cambiar docenas de archivos con propiedades localizadas, que ni siquiera fue considerado por cualquiera excepto yo extraño ...

— Marinero danubiano
fuente

7

PrimeFaces se basa en jQuery, por lo que tiene mucha flexibilidad en el lado del cliente, también los componentes de PrimeFaces proporcionan muchos ganchos en el lado del cliente y del servidor como devoluciones de llamada de eventos para que pueda personalizar. Las API de JavaScript se pueden anular y CSS también para un aspecto personalizado. : la etiqueta se puede configurar globalmente en web.xml para un carácter más amigable con jQuery.

— Cagatay Civici

1

Convenido. La regla general es: El uso de ningún marco requiere programación avanzada de JavaScript y será difícil de mantener, pero permite una potencia y complejidad significativamente mayores, mientras que la dependencia de los marcos será más fácil de construir y mantener, pero limitará la capacidad potencial de la aplicación.

— KTys

10

Los beneficios de usar JSF no son solo la generación de xhtml + css + js. A veces, JSF impone una restricción en el marcado que puede generar, como cualquier marco basado en componentes. Pero JSF no es solo para eso, su ciclo de vida ayuda enormemente. Después de validar la entrada, puede actualizar el modelo y sincronizar los beans del lado del servidor sin ningún esfuerzo. simplemente diga "lo que el usuario escriba aquí, verifique si es un número, si es así, guárdelo en la propiedad YY del objeto XX" y JSF hará todo eso.

Así que sí, todavía puedes usar JQuery, JS, etc. Pero JSF ofrece muchos beneficios cuando se trata de escribir código del lado del servidor y te ahorra muchos problemas.

— arg20
fuente

9

Estoy totalmente en desacuerdo con que jsf agregue algo. Solo agrega gastos generales. Hacer cosas de la interfaz de usuario en el servidor es lo más ridículo que he escuchado. Y javascript en equipos grandes funciona muy bien, se llama reutilización de código.

Simplemente envuelva el jquery en algunas etiquetas jsp, eso es todo lo que necesita y ya está, y no sufra los problemas de .shackles y escalabilidad con .jsf y richfaces.

— guwst
fuente

14

JSF está orientado a aplicaciones basadas en formularios. jQuery es bueno (diablos, muchas bibliotecas de componentes JSF populares como PrimeFaces, RichFaces e IceFaces incluso lo usan debajo de las cubiertas), pero jQuery no simplifica el procesamiento de envíos de formularios en el lado del servidor de ninguna manera. El uso de JSP / Servlet simple solo dará como resultado un código repetitivo terrible. Nuevamente, JSF no es solo HTML / CSS / JS, sino también JSP / Servlet.

— BalusC

2

Creo que si lee más sobre JSF en general y sobre el ciclo de vida de una página JSF específicamente, podría cambiar de opinión. Por otra parte, puede que no.

— Ahmed Anwar

5

Habiendo trabajado con JSF, Spring MVC, Struts, Grails, JQuery y ExtJS, mi opinión es que Grails + ExtJS es una combinación poderosa.

Elegiría Grails sobre JSF cualquier día. Me gusta la integridad de ExtJS como el marco y la biblioteca del lado del cliente, pero viene con una curva de aprendizaje más pronunciada que JQuery.

— dbrin
fuente

3

Estas son las mayores diferencias entre jQuery y JSF:

sin arquitectura MVC
sin control estatal (almacenar fecha en sesión o conversación, limpieza automática, etc.)
sin biblioteca de validación (predeterminada)
sin biblioteca de plantillas
sin navegación / enrutamiento avanzado
lado del cliente

jQuery nunca fue diseñado para ser utilizado como un webframework de pila completa. Estaba más destinado a reemplazar el código JS de bajo nivel para que escribir JS sea más fácil y más poderoso en menos líneas de código.

Y, por lo tanto, debería usarse principalmente para agregar comportamiento en elementos HTML.

— Serkan
fuente

2

Habiendo usado el framework ExtJS para una gran aplicación web, sé lo fácil que es usarlo. ExtJS (Schena) es más adecuado para interacciones de bases de datos (Oracle 11g) en la arquitectura MVC. La vista fue para las interacciones visual / usuario. El controlador especificó el 'procesamiento' y los activadores que debían usarse desde los paquetes PLSQL (la API para CRUD, consultas de selección SQL, etc.). El modelo y los archivos de la tienda se utilizaron para "asignar" los elementos de datos al visor / entradas.

ExtJS no es adecuado para interfaces web que no utilizan bases de datos intensivas, donde Angular JS puede ser una mejor opción.

— Lukas Knaf
fuente