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

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

¿Por qué debería alguien aprender JSF?

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

Tenga en cuenta que no debe ver JSF como reemplazo de HTML / CSS / JS solo, también debe tener en cuenta la parte del servidor (específicamente: JSP / Servlet). JSF elimina la necesidad de toda la plantilla de reunir los parámetros de solicitud HTTP, convertirlos / validarlos, actualizar los valores del modelo, ejecutar el método Java correcto para hacer las cosas de negocios y generar el código 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 estructura MVC web basada en componentes, tiene en JSF un control menos preciso 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 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 gran ventaja de seguridad). Si eso es, sin embargo, una de las principales atracciones, entonces busque un marco MVC web basado en acción como Spring MVC . Solo tendrá en cuenta que debe escribir todo el código HTML / CSS / JS usted mismo . Además, si retrocedes de Facelets a JSP, también perderás 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 repetitivo JSP / Servlet / HTML / CSS / JS / jQuery en componentes reutilizables, entonces una de las soluciones sería JSF. Las plantillas personalizadas, los archivos de tags y los componentes pueden ayudar en esto. En esa perspectiva, JSF se encuentra por encima de JSP / Servlet / HTML / CSS / JS / jQuery (y también es por eso que es muy importante entender esos conceptos básicos antes de sumergirse en JSF).

Aquí puede encontrar un proyecto basado en JSF que se inicia en el mundo real: Aplicación Java EE Kickoff . Verás que contiene al lado de JSF como buenos HTML5 , CSS3 y jQuery .

Ver también:

  • Diferencia entre Request MVC y Component MVC
  • Diferencia entre JSP, Servlet y JSF
  • ¿Qué framework web Java elegir para jQuery?
  • ¿Cuáles son las principales desventajas de JSF 2.0?
  • ¿Es posible usar JSF + Facelets con HTML 4/5?
  • Cuándo usar , archivos de tags, componentes compuestos y / o componentes personalizados?

JSF fue creado para que las tiendas java no tuvieran que aprender cosas como jQuery y construir JS complejas, sino centrarse en una stack puramente Java. En un mundo donde el tiempo es dinero y muchos lugares ya se están enfocando en el desarrollo de Java, un idioma / pieza menos en la stack hace que el entrenamiento y el mantenimiento sea más rápido y, por lo tanto, más económico.

Añadiré que JavaScript es fácil de convertirse en una pesadilla de mantenimiento en equipos grandes, especialmente si algunos de los desarrolladores en el proyecto no son muy conocedores de la web.

Con Javascript y frameworks como jQuery, tienes total flexibilidad y control total. Con ext, etc., pierde mucho control y debe adaptarse al marco. Con JSF, usted pierde totalmente el control y debe adaptarse totalmente al marco. Se invoca en ciclos de vida, etc. y finalmente no tiene control cuando se puede hacer la llamada al servidor y dónde no. Si vas a hacer algo que se considera “especial”, estás en una posición muy difícil. Y en el mundo de JSF incluso cosas tan básicas como el ordenamiento de tablas multicolumnas o campos donde se puede escribir solo un conjunto limitado de caracteres (como el campo de número) se consideran ‘especiales’.

Sin embargo, mientras más flexibilidad tenga, más errores o malas prácticas podrá realizar. La alta flexibilidad solo funciona con progtwigdores altamente inteligentes, otros convertirán el proyecto en una pesadilla no manejable.

Pero, con JSF y su flexibilidad limitada, siempre hay solo algunas (o incluso solo una) forma correcta de hacer algo. Usted es muy limitado, no puede hacer atajos, debe escribir más XML, etc., pero cuando se adapta al estándar, hay un mejor control en el código que producirán los progtwigdores inexperimentados o poco capacitados. Como resultado, las grandes corporaciones aman a JSF porque es ‘más seguro’ para ellas.

Cuando me mudé de GWT a JSF, me sorprendió, cuántas cosas, eso era natural para mí, se consideraba muy atípico y cuantas cosas simples eran tan difíciles de lograr. Lo que es más, incluso hacer los cambios más pequeños, como agregar ‘:’ signo tras sello, que en la aplicación GWT / jQuery cambiaría una etiqueta generadora de funciones, requería cambiar docenas de archivos con propiedades localizadas, que ni siquiera fue considerado por cualquiera excepto yo extraño …

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

Solo envuelva el jquery en algunas tags jsp, eso es todo lo que necesita y listo, y no resista los problemas de escalabilidad y problemas de escalabilidad con .jsf y richfaces.

Los beneficios de usar JSF no son solo generar 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 eso, su vida útil ayuda enormemente. Después de validar la entrada, puede actualizar el modelo y sincronizar los granos 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 en el objeto XX” y JSF hará todo eso.

Así que sí, todavía puede usar JQuery, JS, etc. Pero JSF proporciona muchos beneficios cuando se trata de escribir código del lado del servidor y le ahorra mucha placa de la caldera.

Después de haber trabajado con JSF, Spring MVC, Struts, Grails, JQuery y ExtJS, mi opinión es que Grails + ExtJS es una poderosa combinación.

Escogería Grails por 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 empinada que JQuery.

Estas son las principales diferencias entre jQuery y JSF:

  • sin architecture MVC
  • sin control de estado (almacenar fecha en sesión o conversación, auto-limpieza, etc.)
  • ninguna biblioteca de validación (por defecto)
  • sin biblioteca de plantillas
  • sin navegación / enrutamiento avanzado
  • lado del cliente

jQuery nunca fue pensado para ser utilizado como un webframework completo. Tenía más la intención de reemplazar el código JS de bajo nivel para que la escritura de JS sea más fácil y más potente en menos líneas de código.

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

Habiendo utilizado el marco ExtJS para una aplicación web grande, sé lo fácil que es usarlo. El ExtJS (Schena) es el más adecuado para las interacciones de la base de datos (Oracle 11g) en la architecture MVC. La vista era para las interacciones visuales / de usuario. El controlador especificó el ‘procesamiento’ y los desencadenadores que se necesitaban usar desde los paquetes PLSQL (la API para el CRUD, consultas de selección de SQL, etc.). El Modelo y los archivos de la tienda se usaron para ‘asignar’ los elementos de datos al Visor / entradas.

ExtJS no es adecuado para interfaces web que no sean intensivas en bases de datos, donde Angular JS puede adaptarse mejor.