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

StackOverflow https://stackoverflow.com/questions/3623911

  •  26-09-2019
  •  | 
  •  

Pregunta

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

Desde la presentación sólo se hizo hincapié en las ventajas de JSF, me gustaría escuchar sobre el 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 JSF considerar el uso de ASP.NET MVC en lugar de JSF?
¿Fue útil?

Solución

JSF 2.0 desventajas? En serio, aparte de la curva de aprendizaje relativo cuando usted no tiene un conocimiento sólido sobre el fondo Desarrollo web básica (HTML / CSS / JS, del lado del servidor en comparación con el lado del cliente, etc.) y la API Java Servlet básica (petición / respuesta / sesión, el avance / reorientación, etc), no hay serias desventajas viene a la mente. JSF en su versión actual aún necesita para deshacerse de la imagen negativa que obtuvo durante los primeros años, durante los cuales hubo varios inconvenientes graves.

JSF 1.0 (marzo de 2004)

Esta fue la liberación inicial. Fue atestado de insectos, tanto en las áreas centrales y de rendimiento que no desea conocer. Su aplicación web no siempre funcionaba como era de esperar intuitivamente. Usted como desarrollador podría correr duro y llorando.

JSF 1.1 (mayo de 2004)

Esta fue la versión de corrección de errores. El rendimiento fue todavía no ha mejorado mucho. También había una gran desventaja: no se puede HTML en línea en la página JSF sin problemas. Todo el sabor de vainilla HTML get rindió antes el árbol de componentes JSF. Es necesario para envolver todo con sabor de vainilla en las etiquetas <f:verbatim> para que sean incluidos en el árbol de componentes JSF. Aunque esto era como por la especificación, este ha recibido muchas críticas. Ver también a.o. JSF / Facelets: Por qué no es una buena idea para mezclar JSF / Facelets con HTML etiquetas

?

JSF 1.2 (mayo de 2006)

Esta fue la primera versión del nuevo desarrollo JSF equipo dirigido por Ryan Lübke. El nuevo equipo ha hecho un montón de gran trabajo. También hubo cambios en la especificación. El cambio más importante fue la mejora de la manipulación de la vista. Esto no sólo JSF totalmente separado de JSP, por lo que uno podría utilizar una tecnología diferente punto de vista de JSP, pero también permite a los desarrolladores HTML en línea con sabor de vainilla en la página JSF sin la molestia con las etiquetas <f:verbatim>. Otro aspecto importante del nuevo equipo fue mejorando el rendimiento. Durante el tiempo de vida de la aplicación Sun JSF Referencia 1.2 (nombre en código que fue Mojarra ya la acumulación 1.2_08, en torno a 2008), prácticamente todos acumulación obtuve envía con (grandes mejoras de rendimiento) al lado de las correcciones de errores (menores) habituales .

La desventaja solamente grave de 1.x JSF (incluyendo 1,2) es la falta de un alcance entre el solicitud y sesión alcance, el llamado conversación alcance. Esta desarrolladores a problemas forzado con elementos de entrada ocultos, consultas de base de datos innecesarios y / o abusando del ámbito de sesión cada vez que uno desea conservar los datos de los modelos iniciales en la solicitud posterior con el fin de éxito validaciones de proceso, conversiones, cambios de modelo y las invocaciones de acción en el más webapplications complejos. El dolor puede ser suavizada mediante la adopción de una biblioteca de 3 ª parte que retiene los datos necesarios en la solicitud posterior, como MyFaces Tomahawk componente <t:saveState>, JBoss Seam ámbito de conversación y MyFaces Orquesta marco de conversación.

Otra desventaja para HTML puristas / CSS es que JSF utiliza el : de colon como ID carácter separador para garantizar la unicidad de la id elemento HTML en la salida HTML generado, especialmente cuando un componente se reutiliza más de una vez en la vista (de plantillas, repetir los componentes, etc). Debido a que este es un carácter ilegal en los identificadores de CSS, que tendría que utilizar el \ para escapar de la i de colonn selectores CSS, lo que resulta en selectores feo y de aspecto extraño como #formId\:fieldId {} o incluso #formId\3A fieldId {}. Ver también Cómo utilizar JSF HTML generado o elemento de identificación con dos puntos ":"? en los selectores CSS sin embargo, si no eres un purista, también leer Por defecto, JSF genera identificadores de inservibles, que son incompatibles con la parte de los estándares web CSS .

Además, 1.x JSF no se distribuye con Ajax instalaciones fuera de la caja. No es realmente un inconveniente técnico, pero debido a la publicidad de la Web 2.0 durante ese período, se convirtió en una desventaja funcional. Exadel fue pronto para introducir Ajax4jsf, que fue desarrollado a fondo durante los años y se convirtió en la parte central de RichFaces JBoss biblioteca de componentes. Otra de las bibliotecas de componentes se envían con orden interna poderes Ajax, así, el conocido uno de los cuales ICEfaces .

A la mitad el tiempo de vida de JSF 1.2, una nueva tecnología de visión basado en XML se introdujo: Facelets . Esto ofrece enormes ventajas por encima de JSP, especialmente en el área de la plantilla.

JSF 2.0 (junio de 2009)

Esta fue la segunda versión, con el Ajax como palabra de moda. Había una gran cantidad de cambios técnicos y funcionales. JSP se sustituye por Facelets como la tecnología vista predeterminada y Facelets se amplió con capacidades para crear componentes personalizados utilizando XML puro (el llamado componentes compuestos ). Ver también ¿Por Facelets es preferible a JSP como el lenguaje de definición de vista de JSF2.0 en adelante?

poderes Ajax se introdujeron en el sabor del componente <f:ajax> que tiene mucha similitud con Ajax4jsf. Anotaciones y mejoras-sobre-configuración convención se introdujeron a matanza el archivo faces-config.xml detallado tanto como posible. Además, el contenedor de nombres predeterminado ID carácter separador : convirtió configurable, por lo que los puristas de HTML / CSS pudo respirar aliviado. Todo lo que necesita hacer es definirla como init-param en web.xml con el nombre javax.faces.SEPARATOR_CHAR y asegurar que no está utilizando el carácter mismo en cualquier lugar de la identificación del cliente, como -.

Por último, pero no menos importante, se introdujo un nuevo ámbito, el Ver alcance. Se elimina otra importante desventaja JSF 1.x como se ha descrito antes. Que acaba de declarar el @ViewScoped frijol para que el ámbito de conversación sin poner pegas todas las formas de retener los datos en las solicitudes posteriores (conversacional). Un grano @ViewScoped vivirá todo el tiempo que estés posteriormente presentar y navegar a la misma vista (independientemente de la pestaña del navegador / ventana abierta!), Ya sea sincrónica o asincrónica (Ajax). Ver también Ver y alcance Solicitud de beans gestionados y ¿Cómo elegir el alcance de frijol verdad?

A pesar de que se han eliminado prácticamente todas las desventajas de JSF 1.x, hay errores JSF 2.0 específicos que podrían convertirse en algo sensacional. La @ViewScoped falla en controladores de etiquetas debido a un problema de pollo-huevo en estado de ahorro parcial. Esta se fija en JSF 2.2 y portado en Mojarra 2.1.18. también atributos personalizados que pasa como el data-xxx HTML5 no es compatible. Este se fija en JSF 2.2 por nuevos elementos de paso a través / atributos de características. Además la aplicación JSF Mojarra tiene su propio conjunto de problemas . relativamente muchos de ellos están relacionados con el a veces comportamiento poco intuitivo de <ui:repeat> , nueva parcial estado de ahorro de aplicación y la se aplican mal el flash alcance . La mayoría de ellos se fijan en una versión 2.2.x Mojarra.

Alrededor del tiempo JSF 2.0, PrimeFaces se introdujo, basado en jQuery y jQuery UI. Se convirtió en la mayor biblioteca de componentes JSF popular.

JSF 2.2 (mayo de 2013)

Con la introducción de JSF 2.2, HTML5 se utiliza como palabra de moda a pesar de que esto fue técnicamente simplemente apoyado en todas las versiones anteriores de JSF. Ver también JavaServer Faces 2.2 y soporte HTML5, ¿por qué se sigue utilizando XHTML . Más nueva característica importante JSF 2.2 es el soporte para los atributos de componentes personalizados, presente, abriendo un mundo de posibilidades, como sin tablas de encargo grupos de botones de radio .

Además de los insectos específicos de implementación y algunas "pequeñas cosas molestas", tales como la incapacidad para inyectar un EJB en un validador / convertidor (ya fijado en JSF 2.3), que no son realmente importantes desventajas en la especificación JSF 2.2.

componente basado en MVC vs Peticiones basadas MVC

Algunos pueden optar que la principal desventaja de JSF es que permite muy poco control preciso sobre el HTML generado / CSS / JS. Eso no es de JSF propia, eso es sólo porque es un componente basado framework MVC, no un solicitud (acción) en base framework MVC. Si un alto grado de control del HTML / CSS / JS es su requisito importante cuando se considera un framework MVC, entonces usted debe ya no se busca en un componente framework MVC basado, pero a una solicitud basada framework MVC como Spring MVC . Sólo es necesario tener en cuenta que usted tiene que escribir todo lo que HTML / CSS / JS repetitivo mismo. Ver también Diferencia entre Solicitud MVC y componentes MVC .

Ver también:

Otros consejos

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

Dos JSF importante inconvenientes:  

      
  1. Gran curva de aprendizaje. JSF es compleja, eso es sólo cierto.   
  2. Su componente naturaleza. Infraestructura basada en componentes trata de ocultar la verdadera naturaleza de la Web, que viene con una gran cantidad de complicaciones y los desastres (como no apoyar GET en JSF dentro de casi 5 años).  En mi humilde opinión
    escondite HTTP de solicitud / respuesta de los desarrolladores es un enorme error. Desde mi experiencia, cada marco basado en componentes agrega abstracción para el desarrollo Web, y que los resultados de la abstracción en una sobrecarga innecesaria y una mayor complejidad.  

y menor inconvenientes que vienen a la mente:  

     
  1. Por ID predeterminado del objeto está compuesto de ids de sus padres, por ejemplo Form1: button1.  
  2. No hay manera fácil de fragmento de comentario de salida de la página incorrecta. Tag <ui:remove> necesita contenido sintácticamente correcta que se analiza de todos modos.   
  3. componentes de otros Bajos 3ª calidad que, por ejemplo, no marque el interior isRendered() método processXxx() antes de continuar.  
  4. La incorporación de LESS & Sencha es difícil.  
  5. No juega bien con el descanso.  
  6. No es tan fácil para los diseñadores UX, ya que los componentes listos para su uso tienen sus propios estilos CSS, que deben ser sobrescritos.

No me malinterpreten. Como JSF marco de componentes de la versión 2 es realmente bueno, pero aún así es basado en componentes, y siempre será ...

Por favor, eche un vistazo a la baja popularidad de la tapicería, Wicket y baja entusiasmo de los desarrolladores con experiencia JSF (lo que es aún más significativo). Y por el contrario, echar un vistazo al éxito de Rails, Grails, Django, Play! Marco -. Todos ellos están basados ??en la acción y no tratan de ocultar desde el programador verdadera petición / respuesta y naturaleza sin estado de la web

Para mí es importante desventaja JSF. En mi humilde opinión JSF pueden los trajes de un cierto tipo de aplicaciones (intranet, las formas-intensivo), pero para la vida real web aplicación que no es una buena manera de ir.

Espero que ayuda a alguien con su / sus opciones que respecta a front-end.

A los pocos inconvenientes que surgen a la mente:

  1. JSF es un marco basado en componentes. Esto tiene restricciones inherentes que tienen que ver con la obediencia a la componente de modelo.
  2. JSF yo sepa sólo es compatible con la POST, así que si quieres un GET en algún lugar usted tiene hacer un servlet llanura / JSP.
  3. La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y front-end JavaScript, y muchas veces estos abstracciones son "fugas" y muy difíciles de depurar.
  4. Estas abstracciones podría ser un buen punto de partida para un desarrollador junior, o alguien que no se siente cómodo con un dominio particular (por ejemplo front-end JavaScript), pero son muy difíciles de optimizar el rendimiento, ya que hay varias capas implicadas, y la mayoría de la gente que el uso de ellos tienen poca comprensión de lo que está sucediendo bajo el capó.
  5. Los mecanismos de plantillas que se utilizan por lo general con JSF tienen nada que ver con la forma en web desigers trabajo. Los editores WYSIWYG para JSF son primitivos y, en todo caso, su diseñador le dará HTML / CSS que tendrá que pasar las edades de conversión.
  6. Las cosas como expresiones EL no son estadísticamente comprobado y tanto el compilador y entornos de desarrollo no están haciendo un buen trabajo en la búsqueda de errores, por lo que va a terminar con los errores que usted tendrá que captura en tiempo de ejecución. Esto podría estar bien para el lenguaje de tipos dinámicos como Ruby o PHP, pero si tengo que soportar la gran hinchazón del ecosistema de Java, que exigir a escribir para mis plantillas.

Para resumir: El tiempo que se ahorra con JSF, desde evitar escribir el / servlet / JSP código repetitivo frijol, podrás gastó x10 para que sea escalar y hacer exactamente lo que quiero que haga.

Para mí el mayor inconveniente de JSF 2.0 es la curva de aprendizaje no sólo de JSF, pero las bibliotecas de componentes que hay que usar con el fin de conseguir que haga un trabajo útil. Considere el asombroso número de especificaciones y normas que tiene trato con que realmente competente:

  • HTML en las diversas encarnaciones. No finjas que no es necesario saberlo.
  • HTTP - cuando no se puede averiguar lo que está pasando tiene que abrir Firebug y ver. Para que usted necesita saber esto.
  • CSS - Nos guste o no. No es realmente tan malo y hay algunas herramientas agradables que hay por lo menos.
  • XML -. JSF probablemente el primer lugar de utilizar espacios de nombres a este grado
  • Servlet especificación. Tarde o temprano va a entrar en la llamada a métodos en este paquete. Aparte de eso usted tiene que saber cómo sus Facelets se excita en XHTML o lo que sea.
  • JSP (sobre todo por lo que usted sabe por qué no lo necesita en JSF)
  • JSTL (de nuevo, sobre todo para hacer frente a marco legado)
  • Expression Language (EL) en sus diversas formas.
  • ECMAScript, JavaScript o cualquier otra cosa que quieras llamarlo.
  • JSON -. Usted debe saber esto, incluso si no lo usa
  • AJAX. Yo diría JSF 2.0 hace un trabajo decente de ocultar esto de usted, pero usted todavía necesita saber lo que está pasando.
  • El DOM. Y cómo un navegador que utiliza. Ver ECMAScript.
  • eventos DOM -. Un tema por sí mismo
  • Arquitectura Java Persistence (JPA) es que si usted quiere que su aplicación tenga cualquier base de datos back-end.
  • Java en sí.
  • JSEE mientras usted está en él.
  • El Contexto Dependencia especificación de inyección (CDI) y la forma en que choca con y se utiliza con JSF 2.0
  • jQuery -. Me gustaría ver que se llevan bien sin él

Ahora, una vez que haya terminado con que se puede obtener con las especificaciones de propiedad, es decir, las bibliotecas de componentes y bibliotecas proveedor va a recoger a lo largo del camino:

  • PrimeFaces (mi componente de la biblioteca de elección)
  • RichFaces
  • MyFaces
  • ICEFaces
  • EclipseLink (mi proveedor JPA)
  • Hibernate
  • Weld

Y no se olvide el contenedor! Y todos esos archivos de configuración:

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

Así que - esto es lo que es fácil? Claro, JSF 2.0 es "fácil", siempre y cuando todo lo que quiere hacer es las páginas web básicas con la mayoría de las interacciones simples.

En pocas palabras, JSF 2.0 es la mezcolanza más complicado y engorroso de las tecnologías juntas encoladas como el que existe en el universo de software hoy en día. Y no puedo pensar en nada me gustaría utilizar en lugar.

  1. desarrolladores sin experiencia por lo general va a crear aplicaciones que son muy lento y el código va a ser muy feo y difícil de mantener. Su simple engañosamente para empezar, pero en realidad requiere una cierta inversión en el aprendizaje si se quiere escribir buenos programas.
  2. Al menos al principio que a menudo se "atascado" en algún problema y se pasan más tiempo leyendo los mensajes balusc en Internet que realmente funciona :) Después de un tiempo que será menos y menos de eso, pero todavía puede ser molesto .
  3. Aún más molesto cuando se entera de que el problema no se debe a que la falta de conocimiento / error, pero en realidad un error. Mojarra era (es?) Con muchos errores, y otra capa de componentes añade aún más problemas. Richfaces fue mayor pieza de software basura que se ha escrito :) No sé cómo es ahora la versión 4. Tenemos Primefaces que es mejor, pero todavía que se ejecutará en los errores o la falta de características especialmente con componentes más exóticos. Y ahora se le tiene que pagar por las actualizaciones PrimeFaces. Por lo tanto, diría que es de errores, pero su cada vez mejor, especialmente después de 2,2 versión fija algunos problemas con las especificaciones. Marco cada vez más madura, pero todavía lejos de ser perfecta (tal vez MyFaces mejor?).
  4. No encuentro que sea especialmente flexible. A menudo, si se necesita algo muy, muy personalizado y no hay componentes que hace eso - que será un poco doloroso. Una vez más estoy hablando desde la perspectiva promedio desarrollador - la que tiene plazos, tutoriales rápidos de lectura y búsqueda stackoverflow al conseguir atascado porque no hay tiempo para aprender cómo funciona realmente :) A menudo, algunos componentes parece tener "casi" lo que necesita, pero no exactamente y en ocasiones puede llegar a gastar demasiado tiempo para que haga algo que usted quiere :) hay que tener cuidado en la evaluación de si es mejor para crear su propia tortura o componente existente. En realidad, si va a crear algo realmente único que no recomendaría JSF.

Así que en breve mis inconvenientes serían:. Complejidad, no muy buena marcha del desarrollo, con errores, inflexible

Por supuesto, hay ventajas también, pero eso no es lo que usted pidió. De todos modos que de mi experiencia con el marco de otros pueden tener diferentes opiniones, así que mejor forma de hacerlo es a modo de prueba por un tiempo para ver si es para ti (apenas algo más complejo - ejemplos no ingenua - JSF realmente brilla allí :) En mi humilde opinión mejor de los casos el uso de JSF es aplicaciones de negocio, como las sociedades de gestión, etc ...

"HTML de salida JSF voluntad Vista-capa y JavaScript que no se puede controlar o cambiar sin entrar en el código del controlador."

En realidad JSF le da la flexibilidad, puede utilizar componentes / de terceros estándar o crear su propia lo que usted tiene control total sobre lo que está representado. Es sólo una XHTML que necesita para crear sus componentes personalizados con JSF 2.0.

Hemos desarrollado un proyecto de ejemplo con JSF (Fue una investigación de tres semana, así que puede que tengamos perder algo de las cosas!)

Intentamos utilizar JSF núcleo, si se necesita un componente utilizamos PrimeFaces.

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

El sitio cuenta con dos casos de uso:

  1. Una página con una rejilla. La rejilla se carga a través ajax y debe apoyar especie y paginación
  2. Una página del asistente de tres pasos. Cada página tiene la validación del lado del cliente (para las validaciones simples) y el lado del servidor de base de validación Ajax (para las validaciones complejas). Cualquier excepción del servidor (de capa de servicio) debe mostrarse en la misma página del asistente sin tener que navegar a la página siguiente.

Hemos encontrado que:

  1. Usted necesita utilizar algunos trucos de omniFaces para hacer que el estado de vista JSF fija. El estado de JSF se corromperá cuando se incluyen las páginas a través de AJAX en la otra. Esto parece un error en JSF y puede ser fijo en próximas versiones (no en el punto 2.3).
  2. El flujo JSF no funciona correctamente con el Ajax (de lo contrario no podría hacer que funcione!) Intentamos utilizar el componente asistente primefaces lugar pero la validación del cliente no parece apoyado y media de tiempo que no era normal flujo JSF estándar.
  3. Cuando se utilizan algunos componentes jQuery como jqGird, y hay que cargar los resultados JSON, entonces se aconseja utilizar servlet puro, el JSF no hará nada para usted. Así que si se utiliza este tipo de componentes, su diseño no cabrá en JSF.
  4. Se trata de hacer algunos scripts de cliente cuando ajax completa por ajaxComplete y encontramos que la PF 4 ha puesto en marcha sus propios eventos ajax. Hemos tenido algunos componentes jQuery y tenemos que cambiar su código.

Si cambia el ejemplo anterior a un no Proyecto Ajax (o, al menos, proyecto menos Ajax) no se quiere un montón de cara anteriores problemas.

resumir nuestra investigación como:

  

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

Por supuesto, nos encontramos con un montón de características interesantes en JSF que pueden ser muy útiles en algunos proyectos, por lo que consideran sus necesidades de proyectos.

Por favor refiérase a los documentos técnicos a JSF ventajas opinión JSF, y en mi opinión la mayor ventaja de JSF, es el soporte completo y enorme de @BalusC; -)

No soy un experto en Java Server Faces en absoluto. Pero en mi humilde opinión la principal desventaja es que está del lado del servidor. Estoy cansado de aprender y utilizar marcos de la capa del lado del servidor web de presentación como formularios web ASP.NET, ASP.NET MVC, Java Server Faces, puntales, marcos de PHP y Ruby on Rails marcos. Me despedí de todos ellos, y dije hola a AngularJS y mecanografiado. Mi capa de presentación se ejecuta en el navegador. Yo no importa si es servido por Windows IIS PHP o ASP.NET en ejecución, o si es servido por un servidor web Apache que se ejecuta en Linux. Sólo tengo que aprender sólo un marco que funciona en todas partes.

Sólo mis dos centavos.

Para mí, el defecto más grande de JSF es pobre soporte para páginas mediante programación (dinámicamente) generados.
Si desea construir su página (página de crear modelo de componentes) de forma dinámica a partir de código Java. Por ejemplo, si usted está trabajando en WYSIWYG página Web constructor. documentación adecuada de este caso de uso en general no está disponible. Hay muchos puntos donde se tiene que experimentar y desarrollo es tranquilo lento. Muchas cosas simplemente no funcionan cómo se puede esperar. Pero en general su posible entrar ilegalmente en él de alguna manera.
Lo bueno es que no es un problema en la filosofía o la arquitectura de JSF. Simplemente no es lo suficientemente elaborada (por lo que yo sé).

JSF 2 traído Componentes compuestos que debería hacer que el desarrollo de componentes fácil, pero su apoyo a la construcción dinámica (programación) es muy pobre. Si a superar tranquila y complicado proceso casi no documentada de la construcción dinámica Componente Compuesto, usted se enterará de que si anida pocos componentes compuestas poco más profundo, que dejan de funcionar, arrojando algunas excepciones.

Pero parece que la comunidad JSF es consciente de esto 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 debe ser mejor con JSF 2.2 al menos si estamos hablando de especificación.

Al comentar sobre mis últimos meses de experiencia Primefaces / JSF:

  • Si puede utilizar componentes "de la estantería", supongo que no es terrible.
  • No obstante, no juega bien, tan pronto como entras interfaces de usuario personalizados fuera y necesita. - Por ejemplo, tuvimos que utilizar de arranque de Twitter para nuestro proyecto. (No PrimeFaces de arranque).
    • Ahora nuestras páginas funcionan de la siguiente manera:
      • carga la página.
      • interactúa usuario con un Primefaces que tiene funcionalidad Ajax
      • Bootstrap de ligaduras con javascript descanso
      • ejecutar JavaScript extra para revinculación todo

La promesa de JSF para evitar escribir javascript convertido en escribir más javascript de lo que tendría si no se usa Primefaces -. Y que es javascript para arreglar lo que se rompe PrimeFaces

Es un sumidero de tiempo - a menos que se utilice de nuevo "fuera de la plataforma" cosas. También muy feos (Primefaces) al tener que trabajar con selenio. Todo se puede hacer - pero de nuevo -. Sólo hay tanto tiempo

Definitivamente evitar esto, si está trabajando con un equipo UX / diseño y la necesidad de iterar rápidamente en la interfaz de usuario - se puede ahorrar tiempo aprendiendo jQuery / escribir HTML directamente - o mirando reaccionar / angular.

JSF tiene muchas ventajas, al estar en desventaja pregunta permítanme añadir par de puntos sobre el mismo.

En un escenario de práctica de implementar un proyecto web con en un marco de tiempo que necesita para mantener un ojo en los siguientes factores.

  • ¿Tiene suficientes miembros de alto nivel en su equipo que pueden sugerir mejor controles adecuados para cada escenario?

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

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

Si su respuesta es 'No' a las preguntas, que puede terminar en una base de código no tienen mantenimiento.

JSF tiene una sola desventaja:. Antes de iniciar el desarrollo "JSF" se debe entender claramente el desarrollo web, java núcleo y arquitectura de front-end

Hoy en día "nuevos" frameworks de JavaScript simplemente tratan de copiar / pegar modelo basado en componentes "JSF".

Entre todos los marcos "principales" como Spring MVC, Wicket, tapicería, etc., el JSF de Java EE con sus componentes de material compuesto es la presentación-capa más elaborado y la tecnología orientada a componente proporcionado. Es un poco engorroso e incompleta en comparación con las soluciones proporcionadas por HybridJava.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top