¿Cuál es la necesidad de JSF, cuando la IU se puede lograr desde CSS, HTML, JavaScript, jQuery?

jquery-ui extjs (8)

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 programadores 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 programadores 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 ...

Estaba leyendo sobre JSF que es un marco de UI y proporciona algunos componentes de UI. Pero, ¿cómo es mejor o diferente del número de componentes que pueden estar disponibles desde Ext JS o jQuery o combinación de CSS y HTML y JavaScript?

¿Por qué debería alguien aprender JSF?

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 arquitectura 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.

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 etiquetas jsp, eso es todo lo que necesita y listo, y no resista los problemas de escalabilidad y problemas de escalabilidad con .jsf y richfaces.

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 arquitectura 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.

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 showcase para ver ejemplos de código completos. BootsFaces (jQuery + Bootstrap UI based) también tiene un showcase 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 etiquetas 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:

JSF fue creado para que las tiendas java no tuvieran que aprender cosas como jQuery y construir JS complejas, sino centrarse en una pila 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 pila 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.

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.