Diego Silva ha publicado en su blog una serie de videos donde se muestran los pasos necesarios para crear una aplicación CRUD con JSF 2.0 empleando Netbeans 6.8 (por cierto, ayer se publicó la Release Candidate 1 de Netbeans 6.8). El código fuente de la aplicación desarrollada en los videos está disponible aquí.
Un buen complemento para estos videos son este tutorial publicado en Netbeans.org.
¿Qué os parece JSF 2.0? ¿Alguno de vosotros a comenzar a trabajar con esta especificación?
He estado siguiendo de cerca todo lo referente a JEE 6 y las versiones de Netbeans 6.8. Pero no salgo, de este ambiente de duda sobre lo que pasara con Netbeans , Glassfish, Mysql. etc.
Al final, parece que, Netbeans- Glassfish solo son o serán herramientas de referencia y que pronto desaparecerán y nos veremos inmersos en usar otros servidores tan pesados como WebLogic, un IDE tan inestable y tan malo como JDeveloper con un Framework que necesitan de tantos artilugios en el lado del servidor y de configuraciones por aquí y por allá (por no decir que te pierdes entre tanto xml que gereran sus famosos wizards, cuando lo que se quiere hoy en menos uso de xml y mas anotaciones) con más de 70 Mb. de librerías por aplicación como es ADF; Sumergidos en una Base de datos tan pesada que necesita de parches mágicos para lograr funcionalidades que otras ya ofrecen de manera nativa.
Dios nos libre....
Adonde vas, manzanas traigo.
Yo, me quedo con Tapestry, sea dicho XD
Pues a PHP y MySQL se ha dicho. NetBeans y JDeveloper son buenos, pero no para chapucillas de ir por casa. Para ello ya está PHP + MySQL.
Desde la aparición de AJAX, JSP, Struts ,Portlets ,etc,etc son cadáveres andantes.
Desde la aparición de AJAX, JSP, Struts ,Portlets ,etc,etc son cadáveres andantes.
Cuanta ignorancia por Dios, cuanta ignorancia... otro que se cree que AJAX lo hace todo todito todo.
Me quedo con la pregunta del articulo...
¿Qué os parece JSF 2.0? ¿Alguno de vosotros a comenzar a trabajar con esta especificación?
A mi particularmente me casua gracia, pero es en el fondo triste, cada vez que alguien postea algo para generar un debate interesante aquí, en java hispano, en la mayor comunidad java de habla hispana del mundo, lo que menos se genera es un debate. Empiezan las rivalidades como si hablaramos de dos equipos de futbol y comentarios tan vacios como...
Desde la aparición de AJAX, JSP, Struts, Portlets, etc, etc son cadáveres andantes.
Si vas a postear algo como esto minimo, aclará tu punto porque crees que AJAX mato a todas estas tecnologías, has utilizado todas estas tecnologias? Porque te parecen malas? Por que no has podido utilizar AJAX y Struts? No se me parece que en una comunidad tan grande como esta el debate da para algo mas inteligente que simplemente decir tal tecnologia es una mierda aguante PHP.
Quiero pensar que la mayoría de la gente que pasa por esta comunidad es culta. He leido comentarios inteligentes y muchos. Espero poder volver a encontrarlos en este viejo y querido java hispano.
Saludos, Sebastian
Respecto a JSF 2.0 ya apareció publicada una noticia hace poco. De aquella noticia, me pareció muy interesante el comentario del anónimo de las 11:26.
La verdad es que hace tiempo quedé desencantado con JSF y me parece más atractivo dedicar recursos a aprender algo como tapestry que, aún a costa de incompatibilidad hacia atrás, se ha deshecho del equipaje y ya no tiene la curva de aprendizaje de antaño.
Sigo con la pregunta original respecto al JSF 2.0.
No cabe duda que una aplicación web realizada con JSF 2.0 proporciona unos componentes visualmente muy ricos (tabpanel, tablas con multiples funcionalidades, menús contextuales, cajas de texto con autocompletar, drap&drop, etc, etc) que si tuvieramos que programarlos por nosotros mismos tendríamos que subir mucho las estimaciones de horas en los proyectos (y claro, para ahorrar costes pues simplemente no se solían hacer antes de aparecer esta tecnología).
Pero desde el punto de vista no sólo técnico, sino también entrando en la gestión de proyectos medios-grandes, veo estos inconvenientes:
* Curva de aprendizaje bastante alta
He participado en varios proyectos donde trabajaba con programadores experimentados que han tardado varios meses en dominar algunos de los componentes que proporcionaba la implementación JSF que usabamos (myfaces, richfaces y facelets). Vamos, que casi hubieramos tardado lo mismo programandolos por nosotros mismos.
Incluso en uno de los proyectos que participé los programadores habían recibido un curso previo de JSF.
Por ejemplo, el ciclo de vida de una petición tardan mucho en entenderlo bien, y no es porque no le dediquen el tiempo suficiente. Es un ciclo complicado. Y puntos como las validaciones, conversiones, manejo de eventos ó navegación entre páginas también son más díficiles de entender que en otras tecnologías (JSP, Struts, etc).
* Limitado por la implementación usada
Aunque JSF permite crear tus propios componenetes, o ampliar los existentes, la realidad es que resulta bastante costoso en tiempo. Las urgencias de los proyectos no suelen dar horas para tales desarrollos. Así que en multitud de ocasiones te ves limitado por la implementación que usas. Y desgraciadamente el cliente siempre pide alguna funcionalidad que la implementación del componente no la proporciona. Consecuencia: te buscas la vida como puedes.
Obviamente es la limitación propia de usar un framework desarrollado por terceros, que tiene sus ventajas claro está, pero también hay que tener en cuenta esta desventaja que indico.
* Penalización del rendimiento por aumento de peticiones al servidor
Aunque JSF permite el uso de javascript, no es recomendable porque complica aún más el desarrollo.
Por otra parte, JSF suele ser combinado también con AJAX.
Esto provoca que aumentan considerablemente las peticiones HTTP al servidor. Con su consiguiente penalización. ¿Habeis probado alguna vez una aplicación JSF en una intranet de empresa con un ancho de banda muy reducido? El resultado es horrible.
Si tienes que desarrollar una aplicación con alto rendimiento, yo me pensaría mucho el uso de JSF.
Y cuidado si la aplicación correrá bajo un cluster de servidores. Porque a veces no se replica el objeto sesión entre ellos (por penalizar mucho), y JSF lo necesita para conocer el estado del componenete. Este tipo de cosas te puede dejar muy mal una vez suben a productivo tu aplicación y NO funciona.
* Objetos de persistencia a la capa de visualización
En uno de los proyectos los managed beans utilizaban los mismos objetos de persistencia de la capa de negocios. Sabíamos que no era lo más recomendable pero se hizo por ahorrar tiempo. Además, nos parecía doble trabajo tener que volcar la información de un objeto de persistencia en un pojo de visualización (ambos idénticos).
El caso es que tuvimos bastantes problemas, supongo que por la serialización.
Si bien está implícito, me gustaría hacer hinapié en algo
Si tienes que desarrollar una aplicación con alto rendimiento, yo me pensaría mucho el uso de JSF.
La raiz de esos problemas de performance que planteas es AJAX, no JSF.Como bien dices, "JSF suele ser combinado también con AJAX", pero no es obligatorio. En otras palabras, AJAX tiene unos requerimientos "altos" en cuanto al ancho de banda necesario; si no puedes cumplir con esos requerimientos, no uses AJAX.
Anonimo: En otras palabras, AJAX tiene unos requerimientos "altos" en cuanto al ancho de banda necesario; si no puedes cumplir con esos requerimientos, no uses AJAX.
Yo alucino con lo que leo, si una aplicación AJAX tiene más requirimientos de ancho de banda es probablemente porque la productividad del usuario aumenta tanto que al final acaba pulsando muchos más clicks por minuto (que generan peticiones AJAX al servidor) que con una aplicación convencional en la que tendrá que tener más calma porque cada click supone una petición al servidor que conlleva la recarga de la página entera y a generalmente la consulta de nuevo en la base de datos de todos los datos que aparecen en la página.
Si eso es así (que yo personalmente no me lo creo), bendito incremento de ancho de banda.
jmarranz yo opino lo mismo. Pero me imagino que también habrá quien abuse del ajax usándolo para hacer validaciones sencillas en el servidor que en otro caso hubieran hecho directamente en javascript.
La penalización en el rendimiento no es solo culpa de usar AJAX, también es por la filosofía JSF. Lo que antes se hacía con una simple función javascript ahora requiere una petición HTTP y posiblemente consulta a base de datos.
Veo que JSF está avanzando pero aún no veo poco maduro. Los experimentos en casa y con gaseosa. Con grandes proyectos apuesto por tecnología más asentada.
Pues anda que no tiene años ya el JSF
¿Se anima alguien a registrarse? es fácil.
Yo tambien soy de los que se queda con Tapestry, comparativamente crear componentes en Tapestry es bastante mas sencillo que en JSF y tambien me parece mejor diseñado y más facil de aprender, por mi experiencia haciendo proyectos en ambas tecnologías Tapestry ha ganado por mucha diferencia tanto que al final en los proyectos de Tapestry he acabado con una pequeña libreria de componentes que se podrían reutilizar en cualquier otro proyecto (los tipicos de tabla paginada, selector de fecha, validadores, etc...), en los de JSF no he conseguido crear ni siquiera un componente propio reutilizable.
Aqui teneis una guia con enlaces de referencia de lo que ofrece Tapestry: http://tecnoblog.entel.es/?p=81
Tanta discusión que es que es mejor PHP-MySQL contra JSP, JSF y otras tecnologías, me hace recordar a los liliputienses, es mejor usar cuchara o tenedor…
Zapatero a tus zapatos… cada cosa fue hecha con un fin, y aunque estoy de acuerdo con que las tecnologías no deben mezclarse en un proyecto (o si es de requerirse, tratar de usar tecnologías hibridas lo menos posible, eso de usar JSP’s que mandan llamar batch scripts o módulos hechos en PERL no es algo bueno).
Con referencia al tópico, no soy muy amante de JSF, ahora que lo han mencionado en este hilo me dado la tarea de ver Tapestry… promete… promete…
Saludos
Gustavo
Creo que cada quien defiende la tecnologia con la que a desarrollado. Algo muy ciento que comnetan cada uno de ellos fue hecho para algo especifico. A mi me encanta desarrollar y lo he hecho en la gran mayoria que se menciona en el foro. AJAX, JSP, Struts, Portlets,JSF, PHP, .NET, ASP, etc, etc
Creo que el problema con respecto al rendimiento es la forma de desarrollar, cuando no se tienen los suficientes conocimientos respecto al lenguage es comun caer en malas practicas.
Respecto a AJAX y JSF a mi me parece muy interesante la combinacion siempre y cuando se haga de una forma adecuada, usando las mejores practicas.
Para los que les parece complicado los componentes en JSF creo que es solo cuestion de decumentarse adecuadamente.
Para los portlets creo que es una forma de dar solucion a sistemas muy grandes. Es una forma muy elegante de dar solucion a sistemas con diversa funcionalidad
Les mando un saludo y espero que le hechen mas ganas y no se desanimen todo es posible si nos documentamos adecuadamente.
Por favor lean un poco más sobre la JSF 2.0. Ya crear componentes no es tan difícil y además de todo esto JSF tiene un excelente soporte en cuanto a entornos de desarrollo.
que pereza que dan algunos comentarios...
¿alguién ha probado ya si con esta especificación la serialización de la vista en cliente ha bajado de peso?, actualmente si tienes unos cuantos form's en la misma página más te vale tener una buena conexión a internet.
No entiendo por qué es frecuente que los hilos que pretender hablar de una tecnología, al final terminan criticándola. Si mirais la pregunta original era para hablar de lo nuevo en JSF 2.0. Y no para volver a cuestionarnos si merece la pena o no.
Evidentemente JSF tendrá sus desventajas, pero que os parece detractores si abrís un hilo nuevo para comentar sólo sus inconvenientes, y dejamos este hilo para hablar de lo que incorpora nuevo.
Se me quitan las ganas ya de hablar de JSF. El hilo se ha desvirtuado.
Tapestry 5. merece la pena hecharle un vistazo, por ejemplo, a la hora de montar componentes con accesibilidad AA se tarda muy poco, en comparacion con JSF. Cuenta con algunos ejemplos, Jumpstart y la libreria de componentes Chenillkeit.
Vaya latita estás dando con el Tapestry.
Al final cada uno que tenga capacidad de decisión en sus proyectos para utilizar una tecnología u otra utilice la que más conveniente crea, con la que más conodo se sienta, más productivo sea, más facil de aprender le parezca o más facil de mantener le resulte ya se llame esta JSF, Tapestry, Wicket, Grails, Struts, etc... (otra cosa no será pero en Java hay frameworks a patadas para elegir).Pero tampoco está demás saber como son y que ofrecen otros frameworks o tecnologias para saber si nos podemos hacer la vida más fácil y placentera en nuestros proyectos.
En cuanto a JSF por lo que he leido de lo que aporta JSF 2 parece que ha simplificado algunas tareas que otrora eran más tediosas.Sin embargo, leyendo el comentario y posterior discusion que ha mencionado más arriba supetorpe parece que todavía le quedan cosas por mejorar.
Los video tutoriales me han parecido muy buenos para hacerse una idea básica de como es JSF de forma rápida.
JMarranz
"¿Se anima alguien a registrarse? es fácil."
No, no es fácil o no funciona (al menos no he podido una cuenta nueva). Lo mismo vale para recuperar contraseñas perdidas (manda el mail de vuelta, pero no deja autenticarse). Finalmente, he mandado varios e-mails a los administradores indicando mi problema y no lo han respondido, luego no queda otra que seguir en el anonimato.
Escribe tu comentario