Me estoy debatiendo si el uso de la Costura, de la Peatonal, JSF o GWT como la fundación para mi la capa de presentación en un proyecto Java.

Reduje mi selección de Java frameworks web a este subconjunto basado en el mercado de trabajo consideraciones, la novedad de la tecnología y las recomendaciones de otros S. O. de los usuarios.

¿Qué factores debo tomar en cuenta al decidir entre estos?

InformationsquelleAutor karl | 2009-04-13

11 Comentarios

  1. 18

    El único de los que yo he utilizado es de JSF, así que no voy a ser capaz de darle información sobre los demás, pero aquí está mi opinión sobre JSF. En mi experiencia, el momento en el que nos convierte de JSF en JSP para JSF en facelets, la vida se volvió MUCHO más fácil, así que me centraré en torno a facelets. También, parece Que la Costura y JSF no son mutuamente excluyentes.

    Pros:

    • La creación de facelets xhtml componentes es simple, que promueve la re-uso.
    • Decente de plantillas de las capacidades construidas en las etiquetas como ui:insert, interfaz de usuario:se incluyen, y la interfaz de usuario:decorar
    • El Simple acceso a la Primavera de granos a través de la faces-config
    • XHTML, a fin de que los desarrolladores web no familiarizados con java, todavía puede ser eficaz
    • Buen widget de biblioteca disponibles en tomahawk/trinidad

    Contras:

    • Peticiones Post solamente. Esto puede hacer que los marcadores difícil.
    • No como built-in ajax-y como GWT, pero esto se puede arreglar si se utiliza con Costura

    Yo soy de ninguna manera un experto en JSF/Facelets, así que estoy seguro de que hay otras que me he perdido. Espero que a alguien más también le elaborados.

    Actualización para JSF 2.0:

    • Tiene incluso mejor re-uso de funciones de los componentes de material compuesto
    • Widget de bibliotecas 2.0 incluyen primefaces y mojarra escalas
    • Permite obtener las solicitudes y marcadores
    • Ha construido en el soporte de Ajax
    • Ver http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ para obtener más información sobre JSF 2
    • tomahawk/trinidad – buen consejo. Gracias.
    • Costura facilita el uso de las solicitudes GET y han marcable Url con JSF.
    • Gracias Pedro, me voy a tener que buscar en ella.
    • Si se busca por «wicket» en stackoverflow, usted encontrará que muchas de las discusiones sobre estos frameworks web que te pueden ayudar. En particular stackoverflow.com/questions/24596/… y stackoverflow.com/questions/538550/…
    • Añadiendo a esta pregunta de marcos, que sería preferible si el seo es importante?
    • No sé mucho sobre seo (estoy asumiendo que significa search engine optimization), pero supongo que ajax/javascript puede interferir con él. Es todo acerca de cómo difundir el contenido aunque, por lo que sospecho que usted podría utilizar con éxito cualquiera de estos dependiendo de cómo se estructura de la aplicación y la presentación. En mi limitada experiencia, yo creo que un completo soplado de GWT aplicación podría ser el más difícil para el SEO.
    • JSF2 incluye el soporte para peticiones GET de una manera similar a cómo JSF1.2 + Costura 2 soporta peticiones GET. La idea de utilizar la Costura 2 sin JSF es un poco extraño (yo he estado usando la Costura desde que salió). De la OMI, de la Costura de los parches de seguridad de la mayor parte de los agujeros en JSF 1.x. JSF2/CDI tiene la mayoría de los que abordar ya, como estoy seguro que usted sabe.
    • Tenga en cuenta que en mi edición hace 3 años, menciono que en JSF 2 soporta peticiones GET. No estoy seguro de que el uso de JSF sin Costura fue extraño que en el 2009 cuando respondió a la pregunta, pero tal vez estábamos haciendo mal. En cualquier caso, me gustaría sugerir fuertemente mirando de otra cosa que de JSF para la nueva interfaz de usuario web de trabajo.
    • Sí, el uso de JSF 1.x sin Costura es bastante doloroso. He estado usando JSF2/CDI para algunos de los nuevos cosas y he encontrado que es fácil trabajar con ellos.

  2. 34

    He usado GWT desde la versión 1.4 y JSF desde la 2.0 especificación salió.

    GWT es un framework del lado del cliente, se genera el código JavaScript de Java. Su arquitectura sería una pura cliente-servidor, lo que significa:

    • Mejor uso de grano grueso servicios
    • Todos los objetos que viajan a el lado del cliente debe ser totalmente serializable (lo que significa que no hay carga diferida, o OpenSessionInView patrón)
    • Desde GWT 2.0 usted puede diseñar su interfaz gráfica de usuario mediante xhtml, que es mucho más fácil en cuanto a estilo & la estructuración de HTML
    • GWT tiende a favorecer la buena arquitectura, si te confundes será mal para refactorizar
    • Perfecto Historial del navegador, botón atrás, marcable url) de apoyo es duro, usted probablemente tiene que rodar su propia, aunque es fácil de hackear algo en la parte delantera

    JSF es un componente basado en marco, con un primer diseño (código-detrás de si te gusta):

    • Es más fácil hacer algún tipo de webapps (stateful, como el carrito de la compra)
    • JSF+Costura tiene soporte para conversaciones (creo que a modo de asistente páginas que mantener el estado a través de varias páginas)
    • Que puede implementar OpenSessionInView, dependiendo de su pila. Es probable que no se recomienda utilizar EJB para el servicio/capa de negocio
    • JSF2 ha excelente soporte para AJAX, y con un conjunto de componentes como RichFaces usted puede construir agradable webapps
      • Pero si quieres exquisito comportamiento con javascript, vas a tener que escribir código javascript
    • JSF pistas de la actual interfaz de usuario de estado en el cliente o en el servidor. Este es un compromiso entre el tráfico de la red o de la memoria del servidor.

    Curriculum vitae:

    • GWT es el más adecuado para la web aplicaciones (creo gmail) que exigen el mejor rendimiento del cliente. Es fácil escribir componentes personalizados (escribir en Java) y desde su lado del servidor es sólo una capa de servicio puede ser totalmente apátridas en el lado del servidor.
    • JSF es el más adecuado para la mayor parte de la SUCIEDAD de las aplicaciones que se adaptan mejor para el componente orientado cosas: creo que un hotel de vuelo y sistema de reservas online de la tienda con un carrito de la compra, etc
    • Se le olvidó a los consejos que él nunca usar GWT o de cualquier otro lado del cliente framework para Java desde estos marcos tienden a ser muy doloroso para los desarrolladores, mucho me elija a mi HTML/CSS/Javascript, en lugar de la construcción de mi página html con código Java y, a continuación, compilar todo en Html/Js.
  3. 15

    Gracias wicket chicos para permanecer sobrio y mantener más de esta discusión. Yo soy un bateador de usuario y me encanta. Mis principales razones son :

    1. Es un componente de marco. Me encanta trabajar con componentes como contraposición a la plena páginas.
    2. Puedo dejar a los diseñadores trabajar en las plantillas de las páginas tal y como yo trabajo en el java partes

    3. No hay nada nuevo que aprender. Su «acaba de java y sólo HTML»

    4. Me gustan sus ajax mecanismo de Reserva. Donde no hay soporte de javascript en un navegador especialmente en dispositivos móviles, se gira de nuevo a la llanura de html y funciona todo.
    5. Su falta de configuración xml es un plus
    6. Es compatible con todo lo que puede desear en una aplicación web. e.g validación, internacionalización, compatibilidad con el botón atrás y reparador Url entre otros

    Mi anterior experiencia en GWT y JSF 1.0

  4. 10

    Costura es un marco de aplicación, no es realmente una capa de presentación. Originalmente fue desarrollado para hacer JSF menos doloroso, pero ha evolucionado hasta convertirse en una finalidad más general de la inyección de dependencia marco.

    Creo que puede utilizar Costura con JSF, de la Peatonal y GWT. JSF apoyo es el primario y excelente; no estoy seguro de qué tan bien los otros dos son compatibles.

    Desde el enfoque de los criterios parece ser la comercialización de sus habilidades, yo sugeriría probar Costura y JSF a través de Facelets. JSF es un estándar aceptado y es realmente agradable de usar si usted está usando Facelets. Usted puede tener mancha de la funcionalidad de AJAX a través de Richfaces y Ajax4jsf. La costura es más o menos estandarizados a través de la JCP.

    • Interesante. ¿Richfaces el empate en JBoss? También recomendamos el Facelets ruta – yo no veo ninguna de ofertas de trabajo que mencionar es esto porque es relativamente nuevo, o porque los postings del trabajo son más propensos a mencionar JSF?
    • JSF fue utilizado por primera vez en JSP y, a continuación, en facelets, pero creo que el JSF grupo favorece facelets. Esto es evidente en el JSF 2.0 especificación que tiene una tabla que muestra las ventajas de facelets más de JSP.
    • Karl – Richfaces debe ser utilizable en cualquier contenedor que soporte JSF, no hay JBoss dependencias de la que soy consciente. Como para puestos de trabajo, yo personalmente evitar cualquier trabajo que requiere JSP; facelets son el camino a seguir. 😉
    • Olvidar JSP. Facelets es la vista predeterminada de la tecnología en la Costura (y JSF 2.0) para la Costura por lo general implica Facelets, aunque hay algunos de la Peatonal de apoyo.
    • No he estado disfrutando de uso de richfaces. Si podía tomar XCSS sin ninguna de las construidas en «basic» XCSS utilizados en el control de la suite, a continuación, sus estaría genial, de lo contrario sus orígenes en un establecimiento educativo son claras como el día. Se pone en el camino y evita que libremente utilizando sus conocimientos especializados existentes en HTML y CSS. De lo contrario, +1 para una buena respuesta. Costura Remoting «simplemente funciona» y se recomienda para el AJAX.
  5. 7

    Mi experiencia es, en orden cronológico:

    Raw servlets – (sí, un montón de trabajo duro pero fue a comienzos de los días y teníamos muchas ganas de castores!)

    JSP – pensé que era el beez neez en el momento en que salió (si sólo sabíamos 😉 )

    Eco – Impresionante marco, pero no para las páginas que necesita para ser el motor de búsqueda amistoso (el mismo
    problema con GWT)

    Wicket – Impresionante marco – los desarrolladores de entender completamente el concepto de la OO (a diferencia de JSP y muchos otros) y se han aplicado todos los habituales OO sutilezas de este marco. Si usted aprecia la reutilización», si usted aprecia la encapsulación, si usted aprecia la separación de las preocupaciones y si te gusta enlazar el modelo de la interfaz de usuario de código sin tener que preocuparse por objeto el cálculo de referencias y otros fealdad, a continuación, este es el marco para usted!

    • Yo nunca fui la llanura servlet ruta (no para la representación html) para que pueda ‘t felicito por eso. Pero tengo algo de experiencia en la construcción de la Peatonal de aplicaciones y ahora (ahora debe) utilizar JSF. Diablos, cómo me gustaría ir de nuevo a la Peatonal. Para algunas personas puede ser más fácil de usar JSF, pero me gusta mucho más que la limpia y sencilla los principios detrás de la Peatonal. Cosas sencillas que son fáciles de hacer y más compleja la tarea no es difícil, ya que la API proporciona enlaces para anular el comportamiento por defecto..
  6. 3

    En un largo plazo, el escenario me gustaría recomendar el uso de tecnologías de la respaldado por un Sol de especificación. Esto ha demostrado dar varias implementaciones resultante en la elección (con frecuencia también de código abierto implementaciones), además de comportamiento tiende a ser muy bien definida.

    Que le ayudarán en el mantenimiento escenario, que – con suerte – tu código va a acabar demasiado en el tiempo. Bien escrito el código vidas para siempre 🙂

    En este escenario en particular me permito sugerir JSF. Sólo he probado el Apache aplicación de la 1.1, pero el dolor de estar en la cima de JSP. Vamos a revisar pronto – espero mirada en tener JSF en facelets.

    • Yo diría que la elección de un Sol especificación no es tan importante como muchas normas comerciales (Struts, Hibernate, Spring, Log4j, etc.) eran el Sol especificaciones y, sin embargo, fueron ampliamente adoptadas debido a su poder y utilidad. Si nada, al éxito de estos proyectos más tarde condujo a la creación de estándares una vez demostrado que definitivamente no es el caso con JSF.
    • Edit: …se NO Sun especificaciones…
    • Yo estaba hablando a largo plazo. Cuál de los marcos de mencionar que esperas para ser admitidos en 10 o 20 años? Código tienden a vivir para siempre.
    • Un downvote? Para decir que el mantenimiento a largo plazo es importante? Y JSF hizo en JEE 6… Oh bien.
    • Upvote de mí. Me fui con Costura 2/JSF 1.x porque creía que, finalmente, la Costura podría resultar en un cambio en JSF. Esto sucedió con JSF2/CDI.
    • Te gustaría recomendar limitar a ti mismo para el uso de las tecnologías de la respaldado por un Sol spec? – No me malinterpretes, me encantó el Sol (cuando fue de alrededor), pero estoy asumiendo que su política significaba que se marcharon sobre el acantilado con todos los lemmings con Sol liberado (unleashed) la más ridícula de la tecnología jamás visto en el mundo de Java: Ejb – Ejb son la razón por la que usted debe cuestionar todo y asumir nada, independientemente de quien la produce.
    • es un pobre artesano que culpa a la herramienta. El problema con Java EE es que fue originalmente diseñado para ser capaz de ejecutar relativamente transparente en varios JVM). Por desgracia para Java EE este no es el típico caso de uso.
    • Estoy sin palabras después de su uniformados insulto… bueno, no exactamente: Obviamente eres una persona que hace masiva suposiciones sin comprometer a su cerebro de primera me encanta Java EE – pasó los últimos 20 años en la construcción de los sistemas que se han ganado clientes en millones de $ con ella. Leer más de lo que me dijo cuidadosamente: estoy haciendo un señalamiento acerca de tomar su consejo de seguir ciegamente a usar todo lo que está respaldado por un Sol spec utilizando EJB 1 como un ejemplo de, posiblemente, el peor de la tecnología Java NUNCA. Usted no necesita ser un pobre artesano odio EJB – sólo necesaria para no tener una lobotomía frontal odio.
    • Primero vamos a revisar la redacción de mi respuesta, porque parece que no han entendido antes de comentar: «En un largo plazo, escenario de me gustaría recomendar…». En otras palabras, cuando se trata de proyectos de espera que tienen una larga vida útil. Mi conjetura sería que usted todavía puede encontrar un proveedor HOY venta y el soporte de Java EE contenedor que podría ser utilizado para su EJB1 soluciones. Para algunos eso es muy importante. Que dijo, llamando a otros para lemmings en línea recta de la azul no es muy educado en el primer lugar :-/
    • honestamente, ¿usted realmente cree nadie, pero un lemming eligieron usar EJB1? Mucha gente no tenía ninguna opción pero que no es su culpa – tomadores de decisiones que se entiende que la tecnología (aunque me temo que a menudo la toma de decisiones están tecnológicamente ni idea) y, a continuación, todavía eligió para su organización porque tenía algunos «oficial» de la aprobación – lemmings! 🙂
    • Todavía no consigue el punto. Incluso si una determinada tecnología es absolutamente fantástico, un arquitecto puede elegir algo mucho menos fantástica, debido a las preocupaciones son más amplios de lo que una sola mente cerrada desarrollador fantasías en su pequeño mundo. Pero, voy a morder, lo recomendaría para un escenario donde el deseado de vida de una solución décadas? ¿Qué le han recomendado hace 10 años? 20?

  7. 1

    He usado de la Peatonal y GWT con bastante profusión. En realidad nunca aprendí a amar la Peatonal.

    Mi ego blogs sobre ello http://salk31.blogspot.com/2009/07/wicket-ajax.html

    Mirando GWT 2.0 uiBinder hoy me recordó lo molesto que estaba en la Peatonal a tener que coincidir con el componente XML de árbol con la que ha sido creada en Java. El GWT vuelta en esto se ve infinitamente mejor para mí.

    No he usado la Peatonal de más de un año, así que tal vez se han arreglado mucho de esto, pero dado navegador moderno y JS apoyo no veo el punto de hacer todo esto en el servidor (yo sé, yo sé localidad de los datos).

    • Depende de cuánto el valor de su propiedad intelectual. Con Wicket el código/IP de todos sigue siendo seguro y seguro servidor. Si no valoras tu IP que mucho, entonces seguro, escribe la mayor parte de la interfaz de usuario código JS ponerlo a disposición de sus competidores a estafar mediante el envío de todo para que el navegador no compilado, fácil de hacer ingeniería inversa de JavaScript. No me malinterpreten, Wicket hace amplio uso de JS para hacer altamente eficiente y sensible interactivo de la UIs, pero en una forma que no exponga a su dominio de los modelos o algoritmos.
  8. 1

    Si usted considera solo mercado de trabajo , usted debe elegir JSF. Pero, creo que el futuro de la RÍA pertenece a GWT y gwt como tecnologías del lado del cliente.

    Creo que la más obvia ventaja de GWT, es mejor escalable de lado del servidor de la capa de presentación de tecnologías tales como JSF, de la peatonal. Porque , servidor no es necesario para almacenar el estado del cliente y el cliente de energía de la cpu también se utilizan también.. es un gran beneficio, no es necesario serializar estado de cliente entre los equipos de servidor para lograr tolerante a fallos del sistema.

    • Ahora es de 6+ años más tarde, ¿todavía crees GWT propiedad de ese futuro?
    • No , yo no.. JavaScript ha dominado el mercado.. Pero la parte de mi previsión era cierto; el lado del cliente tecnologías ha dominado el mercado.. Las complejidades de GWT ha asustado a la mayoría de los desarrolladores.
  9. 1

    Empecé con JSF (1.1 y 1.2) y era tan doloroso que me decidí a cambiar en los próximos proyectos. He investigado un poco y me decidí a probar el Palo, y fue así que un placer.
    También he tratado de JSF 2, pero sigue siendo la misma cosa.

    Ambos de ellos son marcos de componentes, pero las cosas con Wicket son fáciles, mientras que con JSF son un completo desastre.

    De la peatonal de más de JSF:

    • En la Peatonal de HTML HTML. JSF tiene su propia marca de etiquetas. El h:dataTable (para las tablas) es una tontería. Créanme, el Sol que los Ingenieros tuvieron que estar borracho cuando lo diseñó.
    • En la Peatonal de aspectos como la seguridad,
    • Con JSF la barra de navegación muestra la URL anterior. Realmente extraño.
    • JSF me parece muy pesado, y con las bibliotecas como Ricos Primos o incluso más.
    • A veces, parece imposible saber lo que está sucediendo. Usted siempre terminan gritando a su equipo, ya que no sé por qué JSF está haciendo.

    JSF sobre la Peatonal:

    • En la Peatonal vas a tener que escribir más de Java (la unión con HTML). Al menos, su IDE proporcionará la refactorización y soporte de validación.
    • La gestión de los recursos en la Peatonal es un poco complicado.
    • Hay mucha más documentación y soporte para JSF

    Común el defecto es que el tamaño de la sesión es problema (porque la gráfica de los componentes se almacenan en allí).

    Con todo, si usted tiene que decidir sólo entre el Palo y el JSF no hay duda para mí, de la Peatonal.

    • HTML == HTML en la peatonal? Sí, pero no se olvide que usted necesita para reflejar todo el árbol de componentes en Java y asegúrese de que se mantienen sincronizados. Este es un gran precio a pagar y por lo tanto una muy engañosa beneficio. En JSF definir el árbol de una vez y sólo una vez en la plantilla de vista. Facelets también tiene un modo HTML (ver página de wikipedia Facelets) y JSF 2.2 tiene «passthrough elementos».
    • Barra de navegación muestra previamente URL?! Eso es sólo si se utilizan normas de navegación sin redirigir. Pero 1. Usted no tiene que usar las normas de navegación y 2. Usted debe utilizar PRG patrón (post redirigir get) o llanura de conseguir enlaces. Su experiencia parece ser la base de un antiguo JSF versión aquí.
    • JSF peso pesado en comparación con el Palo??? Sí a la derecha… JSF utiliza menos recursos (menos de la CPU y menos memoria) de la Peatonal hace. Verificación de puntos de referencia como la «world wide wait». Una vez más, su experiencia parece ser con la antigua JSF versiones que no había parcial del estado de ahorro todavía.
    • Yo nunca he encontrado el reflejo en el árbol de componentes en Java una enorme carga para el Wicket. Hay un ComponentResolver interfaz que puede ser anulado. Usamos esto para permitir el marcado prácticamente a la unidad de la asamblea de los componentes. Le proporcionamos una lista de todos los componentes disponibles y, a continuación, marcado puede ser cambiado a voluntad y los componentes pertinentes se agregan como dirigido por el marcado por lo que proporciona un componente Java gráfico que coincide con el margen de beneficio es totalmente automático. También Wicket 7 ahora añade un Componente de Cola que hace que la gestión de el lado de Java fácil.
  10. -10

    JSF está en desuso (JSF no es ni siquiera aparece como un marco para comparar cuando los evangelistas comparar o hablar de frameworks web en 2010).

    Completo ahora salen del nido aplicaciones de gran escala son creados usando GWT, YUI, JQuery, etc.

    Leer algunos artículos sobre google y encima será obvio.

    (TODOS los PUESTOS de trabajo en JSF son para apoyar a las aplicaciones heredadas).

    • Interesante. En mi humilde opinión, todos ellos será obsoleto en 2 años.
    • Cuidado para proporcionar una referencia a la fuente de esta información?
    • Lo mejor de mi conocimiento, esto es impreciso.
    • JSF hecho en Java EE 6.
    • Esto simplemente no es cierto. JSF2 es ahora, y define Facelets como el punto de vista de la tecnología, mientras que la desaprobación JSP como una vista de la tecnología.
    • Y 8 años más tarde, JSF está todavía vivo, actualizado, solicitado y coleando.

Dejar respuesta

Please enter your comment!
Please enter your name here