Publicado un nuevo número del podcast de javaHispano. En esta ocasión realizaremos una tertulia para hablar de IceFaces donde Marioko de la comunidad de javaHispano y Ivan Zaera de la empresa Autentia, empresa responsable de la web AdictosAlTrabajo, explicarán para que sirve este framework y hablarán de sus experiencias.
Durante la entrevista hablaremos de JSF, Facelets, Server Push, validación de campos y algunas recomendaciones para desarrollo web con este framework.
A continuación ponemos algunos links de interés que se explican durante el podcast:
Etiquetas: j2ee, icefaces, jsf
Muy Buen Podcast, para mí de los Mejores!!
una pregunta para Marioko, ¿cómo realizan la parte visual de la aplicación en tu trabajo si la integración de Facelets y ICEfaces en netbeans aún no permite la programación visual?, me interesaría escuchar todas las recomendaciones posibles.En Eclipse es posible esto? o algún otro IDE?
Saludos!!
jejej bueno, creo que se me olvido mencionarlo, aunque mencione que netbeans soporta edicion visual de paginas icefaces, yo siempre he utilizado el editor de codigo, precisamente porque primero el editor visual todavia no soporta facelets, y segundo nunca me ha convecido ese diseñador que trae netbeans, creo que hay eclipse lleva la delantera y el de eclipse si soporta facelets.
Ademas como siempre trabajo con pequeños fragmentos de pagina es super facil editar todo a mano, despues voy componiendo la interfaz usando esos fragmentos y listo.. xD
saludos, y me alegro que te haya gustado el podcast
muy bueno el podcast, gracias !
Durante este último año, he trabajado con RichFaces y NetBeans, pero a partir de este mes de Julio, en la empresa que trabajo, se piensa implementara ADF y JDeveloper y todo por que el jefe se ha dejado convencer por la gente de Oracle, que, dicen que es el mejor framework y más rápido, además de que la DDBB y el servidor que se usa en la empresa es de Oracle, en fin mi jefe es un fanático de JDeveloper etc. Personalmente he probado un poco ADF a manera de ir familiarizándome, pero he visto que es un framework que crea demasiados xml y no te permite tener una interacción directa con el código java esto me parece molesto ya que estoy acostumbrado a tener control sobre mi aplicación. En fin me gustaría saber cuáles serian las ventajas de IceFaces con respecto a ADF y RichFaces y porque motivo debería proponer se use IceFaces. Si alguien me puede echar un cable se lo agradecería.
Lo bueno de ADF + ADF faces + JDeveloper es que el IDE esta pensado para este framework y es capaz de hacer el 90% de la aplicacion de forma automatica, con clicks y poco codigo, el problema como mencionas es cuando quieras personalizar algo, ya nose como se haria porque nunca lo he utilizado.
ADF es un framework tipo full stack, que te ayuda desde el manejo de datos hasta las vista (ADFfaces o ADFSwing), ADFfaces desde hace un buen tiempo que no lo pruebo asi que nose que cosas nuevas traera.
RichFaces vs ICEfaces si tiene muchas comparaciones, mencionare algunas: la que se ve a primera vista es el uso de AJAX, con richfaces tienes que definir zonas o regiones dinamicas (ajaxificadas), en ICEfaces todo por defecto y sin esfuerzo esta ajaxificado, la creacion de componentes con RichFaces es mas facil por el componente canvas que incluye. Richfaces no soporta Ajax Push, ICEfaces tiene mejor soporte en los IDEs, richfaces tiene mejor soporte para creacion de temas, entre otras.
Si buscas en los foros de Richfaces y en los foros de ICEfaces: "ICefaces vs Richfaces" encontraras todas las diferencias. Por cierto las camisetas de ICEfaces son mucho mejores! ;-P
Da gusta escuchar a gente que tiene un conocimiente tan profundo de estos temas.
Muchas gracias.
Felicidades por el podcast!! Muy bueno!
Muy interesante este podcast, de los más interesantes que he escuchado en JH.
Ivan y Marioko abordaron muy bien los detalles tecnicos que se trataron.
Algo que me parece confuso es el comentario acerca de que Facelets da mejor rendimiento que JSP porque el primero es "parseado" y el segundo es compilado; cuando tecnicamente tiende a ser lo inverso. Aqui supongo que Marioko se quizo referir a velocidad para ver los cambios en el proceso de desarrollo, lo que generalmente se entiende diferente a rendimiento o performance.
Con este podcast se me han despertado las ganas por el mundillo JEE.
Gracias Marioko e Ivan.
muy buena observacion rogerjose, y es comprensible tu argumento, mas bien no me explique bien, pero en realidad Facelets proporciona mas rendimiento que JSP cuando se utiliza con JSF. A ver si me explico:
JSF = Componentes: Los componentes normalmente se organizan en un arbol (Component Tree)
JSP = Servlets: Los servlets no tienen nada que ver con componentes simplemente encapsulan el HTTP de toda la vida.
JSF + JSP?? mmm como que no cuadra por lo mencionado.
Cuando una pagina JSP es ejecutada por primera vez, el codigo JSP (HTML + Java + Tags) es parseado a codigo Java (se crea una clase, que es un servlet) y luego se compila. Cuando está JSP solo es muy muy rapido, pero cuando agregas JSF entonces se complican las cosas, porque los componentes JSF necesitan ser "inteligentes" para mantener su estado, ejecutar eventos, databinding y otras cosas. Entonces muchas veces pasa que el compilador de JSP va por su lado y el motor de JSF va por el suyo lo que hace que se tengan resultados inesperados y se haga mas lenta la aplicacion.
Facelets por el contrario descarta cualquier relacion con JSP y esta pensado para integrarse perfectamente con JSF, en facelets las paginas (XHTML + Componentes JSF) se tranforman de tal forma que hacen parte del arbol de componentes, ahora todo es componentes "ligeros" que se manejan de forma coordinada, esto brinda la posibilidad de optimizar al maximo el proceso de rendering y finalmente mejorar el rendimiento. Esta coordinacion ademas tiene la ventaja de "velocidad para ver los cambios en el proceso de desarrollo", permitir realizar composiciones, usar plantillas y otras cosas.
Bueno espero que eso mas o menos aclare tu confusion, para mas info busca: JSP vs Facelets.
saludos
@Marioko
Richfaces soporta Ajax Push y Poll desde las últimas versiones.
Un saludo.
PD: Buen Podcast.
"Richfaces soporta Ajax Push y Poll desde las últimas versiones."
jeje me lo imaginaba pero no estaba seguro, gracias por confirmar!
Respecto a AJAX push en Richfaces, lo que he visto no es de verdad AJAX push, es una forma de polling, para la gran mayoría de las necesidades polling vale, pero no es de verdad AJAX push (long polling) como sí hace IceFaces.
http://jsfunit.demo.jboss.com/jboss-jsfunit-examples-richfaces/richfaces/push.jsf
@jmarranz
Tienes razón, si utilizas un servidor que soporte comet, está claro que icefaces puede manejarlo, haciendo innecesario el lanzar peticiones desde el cliente al servidor. Pero convencer a mi empresa para que installe glassfish (con el plugin) o el tomcat 6 comet,... aún no creo que me dejasen :)
Aunque está claro que es el futuro (bastante reciente!) ;)
Un saludo y como me encanta aprender en está página.
No necesitas un servidor de aplicaciones moderno para hacer funcionar Comet
muy cierto, de hecho ICEfaces se las juega toda, si el servidor donde se ejecuta no soporta comet, el framework utiliza su propia implementacion y sigue cometiando. Por ejemplo Tomcat por defecto tiene el mecanismo de ARP apagado (muy util para cometiar) pero aun asi ICEfaces funciona.
Mmm hablando de comet y aprovechando que jmarranz anda por aqui, quisiera preguntarle:
¿en ItsNat has tenido en cuenta las limitaciones de HTTP para realizar muchas peticiones simultaneas al mismo dominio/servidor?
Lo digo porque ICEfaces tiene un Push Server que es una aplicacion web normal que se despliega en el server. Esta se convierte en el unico punto donde se procesan todas las peticiones tipo comet para todas las aplicaciones ICEfaces que esten desplegadas en ese server. De esa forma se pueden tener muchas aplicaciones ICEfaces independientes desplegadas en el server y todas funcionando con ajaxpush de forma escalable. Las razones detalladas de esto estan explicadas en el Developer Guide
PD: Cometiar (segun la real academia javaespañola): Accion o efecto de realizar peticiones y respuestas asincronas usando server push ;-P
Supongo Marioko que te refieres al número de conexiones HTTP máximo que permite un navegador.
http://cometdaily.com/2007/11/11/the-dreaded-2-connection-limit/
El estándar HTTP recomienda 2, es una recomendación no una imposición creo recordar.
Sea o no una recomendación, los navegadores se la saltan a la torera:
http://cometdaily.com/2008/09/05/google-chrome-good-news-for-comet/
http://cometdaily.com/2008/03/05/ie8-6-connections-per-host/
El gran problema es IE 6 y 7 que por defecto tienen dos conexiones, ambos navegadores están destinados a desaparecer en el escritorio (excepto en móviles en donde IE 6 vuelve con fuerza en Windows Mobile >=6.1.4), pero hay que reconocer que la cuota de mercado es muy grande a día de hoy.
Todo depende del ámbito de uso, Comet en su forma long-polling en mi opinión no será una tecnología de gran público (para eso está el polling) por lo que los usuarios de long-polling en cierto modo estarán más "seleccionados" y por tanto es más fácil hacerles llegar el mensaje:
"No uses IE 6 o IE 7 o bien si los necesitas incrementa el número de conexiones como dice aquí:"
http://support.microsoft.com/kb/282402
Hace poco leí que la técnica que usa IceFaces en el cliente para compartir conexiones AJAX es usar cookies compartidas entre ventanas. Es un hack raro pero al parecer les funciona.
A mi es un tema que no me preocupa demasiado por lo dicho anteriormente, los navegadores de escritorio por defecto tienen un número de conexiones significativamente mayor que 2, en IE 6 y 7 (no hace falta en IE8) se puede ajustar y en navegadores móviles no lo he probado pero hay que ser un poco rarito para tener varias ventanas a la vez en dispositivo móvil (bastante incómodo es tener una).
Por otra parte siempre es posible crear un subdominio por aplicación, ejemplo:
app1.javahispano.org/app1
app2.javahispano.org/app2
De esa manera la limitación de 2 conexiones sólo se aplica a las conexiones que van a un mismo dominio. Crear subdominios está al alcance de cualquier hosting Java incluso en los compartidos.
Por último ItsNat está orientado a aplicaciones en una página web (single page interface) en ese ámbito no hay mucha necesidad de tener varias ventanas a la vez de la misma aplicación (y además teniendo abiertas dos "sesiones" Comet).
No es por minusvalorar el trabajo de la gente de IceFaces, que es estupendo, pero este tema yo no lo veo como algo crítico.
en realidad es un tema que yo no comprendia muy bien, de hecho, me entere de que existe al leer la guia de desarrollador de icefaces.
Supongo Marioko que te refieres al número de conexiones HTTP máximo que permite un navegador.
jeje yo tambien supongo que me referia a eso mismo ;-)
Bueno de todas formas tu explicacion es muy esclarecedora y desde que estoy usando icefaces siempre me he enfocado en los browsers mas actuales (chrome, FF3, IE7+), asi que no tendre problemas por esa parte. xD
Por otra parte siempre es posible crear un subdominio por aplicación, ejemplo..
Esa alternativa la habia pensado pero no estaba seguro si funcionaba porque obviamente no habia terminado de entender todo el problema.
Por último ItsNat está orientado a aplicaciones en una página web (single page interface) ...
jeje pues ya somos dos xD, desde que conoci AJAX (javascript puro) siempre he intentado en lo posible crear aplicaciones web single page interfacey con ICEfaces es super facil, estas aplicaciones son mucho mas faciles de mantener y organizar y la velocidad de respuesta de toda la interfaz es mucho mejor.
Yo pretendo ir más lejos y promover el single page interface para sitios web no solamente aplicaciones. Con técnicas de AJAX bookmarking se puede conseguir que sigan existiendo bookmarks de "falsas páginas" (más exactamente "estados fundamentales") y que pueda indexar Google la web completa.
Pronto innowhere.com será single page interface.
Yo creo que el single page interface junto con Comet formarán la Web 3.0, desde un punto de vista técnico, es decir el fin del páginado de las webs y el añadido del tiempo real.
totalmente de acuerdo, yo tambien creo que el futuro de la web (cualquier tipo de web) sera SPI + Comet. La navegacion entre paginas nunca me ha gustado y desde un punto de vista artistico es anti-estetico.
Mmm y ahora que mencionas los bookmarks y los estados fundamentales (me gusta el nombre xD) creo que en mi caso podria conseguirlo facilmente con un filtro que analice la URL, configure el estado de la app dependiendo de ella y "redireccione" a la pagina principal con el nuevo estado. De hecho yo para mis proyectos icefaces cree un micro-framework que permite "navegar" entre los fragmentos de paginas principales (estados fundamentales) utilizando nombres de rutas falsos pero no afecta la URL en el navegador sino es una utilidad para programaticamente cambiar el estado fundamental de la aplicacion.
Yo lo uso asi:
WebModuleManager.getInstance().navigateTo("Facturacion/ventas/crearFactura");
donde la String es "Modulo/Seccion/Action" xD
Lo que me faltaria seria escribir esa ruta en el browser y con un filtro invocar ese metodo... mmm (que buena idea me has dado) Me sera muy util para otros tipos de web :-)
Sí eso es más o menos lo que hago yo.
Malas noticias para el "Single Page Interface".
Google App Engine sólo soporta sesiones replicadas (no sticky sessions), IceFaces no soporta por ahora sesiones replicadas, tampoco ItsNat. El soporte de sesiones replicadas son un tormento para cualquier framework con mucho estado en el servidor.
Me ha decepcionado un poco el Google App Engine pues impone muchas restricciones, una la de las sesiones replicadas, otra que no se permiten crear hilos ni retenerlos (pues si un hilo se retiene "mucho " tiempo lo tumba tengo entendido) y la lista de clases Java permitida es muy reducida, por ejemplo no se soporta ninguna clase Swing y eso que en Swing hay muchas clases sin dependencias gráficas tal y como los data models.
He conseguido al menos que ItsNat funcione en Google App Engine sin AJAX (es decir navegación por páginas) y sin uso de componentes con dependencias de Swing (esto estará en la siguiente versión 0.6.1 o 0.7), algo es algo.
IceFaces por su parte prometen sesiones replicadas en la version 2 lo cual les acercará bastante al soporte de GAE.
ICEfaces no soportaba!
La version 1.8.0 incluye Soporte para replicacion de sessiones y clustered fail-over para alta disponibilidad. Tocaria probarlo haber si funciona de verdad pero al menos eso dice el change log.
http://jira.icefaces.org/browse/ICE?report=com.atlassian.jira.plugin.system.project:changelog-panel
Todo esto esta muy bien, llevar Swing a la Web, pero que pasa con los botones del navegador, como se comporta ICEFaces con ellos, igual que el resto de implementaciones de JSF.
He utilizado otras implementaciones de JSF y por lo menos yo he llegado a la conclusión de que JSF no es compatible con una navegación que un usuario "no programador" suele hacer. Los usuarios "normales" tienden (algo razonable) a utilizar lo que normalmente utilizan en cualquier navegación web normal, por ejemplo mirar su correo.
La navegación orientada a acciones con integración AJAX no me parece disparatada...
Buen podcast!
No se como lo hacen en IceFaces pero permitir serializar el estado del servidor no es suficiente, o mejor dicho puede ser suficiente pero es terriblemente ineficiente.
Hasta donde yo se, en sesiones replicadas los datos que se guardan en la sesión de una instancia son propagados a las sesiones de otras instancias del cluster automáticamente. Esto supone que siempre has de obtener los datos de la sesión para asegurar que estén "frescos".
Esto está muy bien en navegación por páginas en donde apenas se guardan unos pocos atributos temporales en la sesión, pero en aplicaciones con mucho estado en el servidor, para empezar el estado se gestiona en una multitud de objetos por el propio framework, es decir, no está tan granularizado como un simple "nombre_producto_lista_de_la_compra", si asocias dicho árbol a la sesión a través de un atributo el contrato de replicación exige que tu árbol sea serializable. El problema no es la serialización que con esfuerzo se puede conseguir, el problema es la sincronización:
¿eliminas y vuelves a añadir el atributo para indicar que ha cambiado ALGO en el árbol?
¿cuando cambia ALGO en el árbol es eficiente que el gestor de sesiones replicadas serialice el árbol ENTERO?
¿nos inventamos un montón de atributos sesión para representar el estado del árbol y conseguir a cambio una cochinada horrorosa de software?
¿recurrimos a un sistema granular de notificaciones (un trabajo inmenso)? Parece que GAE soporta JCache, pero insisto un trabajo inmenso y que contaminaría masivamente el código para conseguir la única ventaja que se consigue con la replicación de sesiones: el failover. ¿Tú aplicación de verdad es tan crítica que el failover que proporcionan las transacciones a nivel de base de datos no son suficientes? ¿es tán problemático que el usuario vuelva a hacer login de nuevo porque se ha caido la instancia que le servía?.
Una solución alternativa sería usar Terrcotta que por lo poco que se sobre el mismo encajaría a la perfección pero el memcache de GAE no llega ni de lejos a la distribución transparente que ofrece Terracotta. Google please mete Terracotta en GAE.
Se admiten ideas.
el usar failover, desde mi punto de vista, solo se justificaria en aplicaciones que necesitan alta disponibilidad, donde el usuario tienen que estar siempre conectado (en todo el sentido de la palabra), o algo asi.. para una gran cantidad de proyectos el reiniciar la sesion (volver a logearse) no es ningun problema, si se cae la conexion y se pierde toda la sesion simplemente volver a iniciarla y seguir trabajando.
Sobre GAE voy hacer alguna pequeña app icefaces que utilice ajax push a ver como se comporta, y a ver si siquiera inicia!! ;-)
Yo también programo "Single Page Interface", y me ha interesado mucho lo que han comentado Marioko y jmarranz, pero mejor primero me pongo a terminar de leer "Core JavaServer Faces" y me salgo de ser un novato, jeje.
@OffTopic: Marioko como le haces para que tus aplicaciones funcionen en Internet Explorer 7y 8 cuando por default el nivel de seguridad de este no permite cookies? y el usuario tiene que habilitarlos a mano y por logica no todos los usuarios tienen conocimiento sobre esto, tienes algunos link a mano por ahi para yo investigar, cualquier cosa será de gran ayuda..
P.D: en los foros de ICEfaces no me respondieron y en el de aqui tampoco.
Saludos!!
la verdad jPedro yo no he hecho nada para que mis app funcionen en IE, lo unico que tengo en cuenta son cosas de las CSS y ya, el resto funciona igual en "todos" los browser. Podrias describir un poco mas tu problema porque la verdad nose que puede ser.
Cuando pruebo mi app en la red local, esta funciona perfectamente en Internet Explorer 7 y 8. Pero subida en el internet es que tengo el problema. Yo tengo un
Si voy y lo configuro manual y le bajo el nivel de protección funciona, el problema es que esta configuración de IE es la que viene por default entonces los usuarios que no saben de eso no podrán utilizar la aplicación.
Puedo hacer algo yo al respecto con ICEfaces?
Puedes responderme en el foro para no desviar este tema:
http://www.javahispano.org/forum/j2ee/es/problema_configuracion_default_ie_no_soporta_cookies/
Como siempre se te agradece, cuando tenga conocimientos fuertes ayudaré a los necesitados al igual que tu lo haces, jeje .
Me dio error con la etiqueta.. queria decir:
Yo tengo un ice:outputConnectionStatus y este muestra el simbolo de conexion desconectada. Entonces cuando verifico porque esta ocurriendo esto en IE veo que dice: "Based on your privacy settings, some cookies were restricted or blocked".
ok seguimos en el foro..
Icefaces es compatible con JasperReport?
Hola Marioko
Tengo una aplicación en iceFaces, en un servidor linux y requere la conexión de muchos usuarios. El problema es que la aplicación está funcionando bien y de pronto se cae el tomcat. ¿Tendrán alguna idea por qué sucede esto?
hola a todos....
muy buen podcast ...!!
estoy haciendo una aplicacion con icfaces 1.8, netbeans 6.5 y glassfish v2 ... me gustaria saber como puedo hacer para que al momento de que un usuario ingrese su clave y aplaste la tecla enter ingrese a la sesion correspondiente, es decir se ejecute el evento del boton submit .... he estado revisando un poco con algo de javascript pero no me ha ido muy bien .... tienen alguna idea????
hola a todos,
primero que todos, muchas gracias por la excelente información post.
en segundo lugar (quizá no sea esta la tribuna pero, ....); Un gran "tirón de orejas" para el grupo Jug.cl (chile) que, está caído hace bastante tiempo (creo que duró un par de semanas y pintaba para bueno); considerando además que, uno de sus más bullados artículos era "La disponibilidad de la Plataforma"(ja, un chiste que tenía guardado hace rato).
Además de lo abandonado del grupo antes señalado, tengo la impresión y sensación que "se perfilaba como un grupo bastante EXCLUSIVO Y ELITISTA". Muy mal, creo yo, en un grupo que promueve herramientas cuya fortaleza radica en la apertura, masificación y desarrollo de tecnologías y productos informáticos en pos del bien común y, por consiguiente, en desmedro de grupos hegemónicos y monopólicos que pretenden el control económico.
Por lo anterior, creo que, el grupo JUGChile presentaba una "cierta" tendencia hacia los anti-valores de la filosofía que promueven excelentes comunidades como esta.
Saludos y muchas gracias,
Escribe tu comentario