Aunque sé que tengo algunos post pendientes con lista de espera, las dos últimas semanas he estado liado con una idea que me ronda la cabeza desde hace tiempo, que contaré más tarde aquí por estar relacionada. Mientras tanto os dejo con una lectura interesante en Baquía, traducción de un post Ron Garret: Geeks, mitos y negocios. La verdad es que subscribo prácticamente todo lo que dice, espero que poco a poco saquéis una idea similar de lo que va apareciendo por aquí.
Menos
Más
Archivo de Etiquetas de 'jsf'
Aunque por distintas razones sólo se puede descargar en forma de EXE de Windows, ProjectioPM esta desarrollado en Java, y es ejecutable vía Java Web Start, nuestra primera intención. En realidad, su editor (el que permite crear las preguntas, más noticias en breve), también es una aplicación Java Web Start. Tengo que reconocer que desde hace años estoy enamorado de algo tan simple y tan elegante como Java Web Start, que permite instalar y actualizar aplicaciones de escritorio a través de la red sin (demasiados) problemas.
Esto me ha hecho considerar la opción de que la interface de Projectio Office (del que ya he hablado por aquí) tenga una aplicación web mínima, pero que el grueso de la misma fuera una aplicación de escritorio.
¿Razones?.
- Cada vez soy más vago y perezoso como para pelearme con el HTML.
- Tengo la sensación de que aún hay muchos usuarios no informáticos de que siguen sin tener claro la diferencia entre aplicación web y aplicación de escritorio. Y que incluso no les gusta la parte web.
- Incluso para los informáticos… ¿abrir una página web?. ¿Y por qué no integrarlo en el IDE (opcionalmente, claro)?.
Inconvenientes también los hay, aunque de momento me los callo, simplemente me gustaría recoger el feedback sobre esta idea. ¿Comentarios?.
Pues nada, desde hace unos días está online otro niño: http://www.e-promocion.es. Con forcex, pero ha salido sin marcas aparentes.
Comentarios técnicos: MyFaces + Shale, JDO 2.0, TPV, uso del protocolo SMPP para el envío de mensajes, un poquitín de AJAX con AjaxAnywhere… . No me dejo nada, creo.
Uno de los mayores problemas que nos podemos encontrar al trabajar con JSF es lo oscuro que puede llegar a ser cuando ocurre un error. Si tenemos suerte y es un fallo de nuestro modelo, nos sacará la traza en la pantalla, si no tenemos tanta, nos lo sacará en los logs del servidor. Pero y si el problema no es de nuestro código (ejem, siempre es de nuestro código ;-) ) y es un problema ocurrido (seguramente con razón ;-) ) en una de las fases del ciclo de vida de una petición JSF (esto lo dejo para otro día si hay peticiones). Simplemente le damos a enviar y volvemos a la misma página. ¿Cómo podemos saber que está pasando?.
La parte fácil, pero que muchas veces se nos olvida es usar los tags message y messages. El primero para un componente concreto, el segundo para todos los errores de la página. Este segundo será de más utilidad si usamos algunos de sus atributos, como por ejemplo showSummary o showDetail. Es un primer paso. Pero, ¿no podemos conseguir más información?. Si, podemos usar Faces Trace.
FacesTrace es una herramienta desarrollada por Cagatay Civici y Yigit Darcin que nos permitirá en todo momento saber que pasa en nuestra aplicación Java Server Faces, mostrando en la misma página toda la información sobre el estado de la aplicación.
La instalación es muy sencilla (es una taglib, ojo a la doc de la web a día de hoy, tiene mal el prefix de la misma), pero su utilidad es grande. Recomendable.
Hace unas fechas ya, hablé los diálogos en Shale. Dije en su momento que la idea me había gustado bastante y así sigue siendo, peeeeeeero (todo tiene que tener un pero :-( ) tienen un pequeñito problema que esta pendiente de resolver.
Y el caso es que como bien se describe en el JIRA del proyecto, es fácil entrar a un diálogo pero no tanto salir de él (o tener varios a la vez funcionando), y parece que van a tardar en arreglarlo.
Una posible solución por si alguno se anima a emplear estos diálogos (de eso va este post!) es la de usar unos mapping que te generen salidas del diálogo para, por ejemplo, las entradas de un menú. Aunque esto tiene varias limitaciones, entre ellas:
- Es un coñazo, poco intuitivo.
- Tengo que mantener esos mapping en varios sitios: la configuración de mi aplicación y la configuración de cada diálogo.
- Repetir lo que sea es tu código es malo, malo, malo.
- Sólo es aceptable para menús pequeños, de pocas entradas, otra cosa es inmantenible (porque automatizar este parche…).
En la página de Shale ya comentan la estabilidad de cada uno de estos módulos. En concreto en lo referente a los diálogos, tenemos:
- org.apache.shale.dialog
- Developing
- Expect further development to support multiple active dialogs in the same page.
Así que no se puede quejar uno, y como diría aquel, eh!, es software libre, hazlo tu mismo ;-).
Os parecerá una tontería, pero ayer estuve jugando con el servicio de diálogos que trae Struts Shale. La verdad es que me ha gustado bastante. Tanto Shale (con el que llevamos unas semanas), cómo con este servicio. Y esto no es tan fácil de decir teniendo la opinión que tengo de Struts Classic.
En fin, vistas las deficiencias de JSF en algunos aspectos, y puestos a seguir estándares, en vez de crear una capa por encima de JSF hemos optado por Shale, y de momento no me quejo. La verdad es que no ofrece demasiado, simplemente una serie de ayudas sobre JSF, que es lo que estábamos buscando.
El caso es que se pueden definir diálogos con el usuario de forma sencilla con:
No sé, teniendo en cuenta que cada vez llevo peor el XML para según que cosas, este casi que ni me ha importado. Me estaré haciendo viejo :-D.
En cualquier caso, el link para iniciar el diálogo:
Aunque Mariscal no se lo acaba de creer, DimeHoteles.com utiliza AJAX en algunas de sus partes. Utilizar AJAX con JSF es algo relativamente fácil: creamos un PhaseListener que intercepte las llamadas y actuamos en consecuencia (el javascript y demás es AJAX en si mismo, nada que ver con JSF). En este post no pretende a usar AJAX con JSF, simplemente comentar un error tonto que puede hacerte perder el tiempo: ¿por qué si envío la respuesta correctamente no puedo procesarla como XML?.
Como sabreis, al recibir la respuesta en nuestra rutina JavaScript, podemos tratarla como XML o como HTML. Si la tratamos como HTML (req.responseText), sólo tendremos que añadirlo a la región de la página que queramos modificar. Pero sin embargo, al tratarlo como XML (req.responseXML), podemos tener la tentación de olvidar una de los partes obligatorios de todo documento XML, su cabecera.
Podemos estar tentados a pensar que poniendo el content-type, el charset y el encoding a nuestra respuesta (a través del objeto response del API de Servlets), nuestro documento será tratado correctamente al procesar el XML. Más aún si también solemos enviar la respuesta en HTML directamente. Craso error. Debemos considerar que esa información es sólo para el envío, y que una vez en el navegador del cliente, se trata como un documento XML tal cual. Y como tal, tiene que tener su propia cabecera XML (), porque de lo contrario nos dará un error al parsearlo, obteniendo un precioso null al hacer req.responseXML.
El problema de ser un blade runner de nuevos frameworks es que más de una vez nos encontramos con problemas que ni el google puede solucionar. En el caso de JSF es fácil encontrarse con infinidad de tutoriales (que más o menos enseñan lo mismo), un buen sitio de tutoriales sobre JSF sería este, por ejemplo.
El problema reside en encontrar sitios que comenten buenas prácticas a la hora de diseñar una aplicación JSF o que describa los errores más comunes a la hora de ponerse manos a la obra. En el caso de el archiconocido struts una de las páginas a las que más utilidad le hemos sacado a lo largo del tiempo es una simple página en la que se describen los errores más comunes y sus posibles soluciones, aquí.
Partiendo un poco de la idea de esa página pero aplicada a JSF, en Linking Paths hemos pensado en dedicar una página de este blog a describir las excepciones más comunes en JSF, sus posibles causas y un detalle de sus soluciones. Y por supuesto os animamos a todos a participar, para ir construyendo lo que puede ser una referencia para el sufrido programador que se adentra en territorios inexplorados ;-)
Podéis enviar vuestros errores (con solución, que no se trata de que esto se convierta en un foro de JSF) a través de los comentarios a este post, que prometo ir incluyéndolos en el cuerpo de la página. Y para predicar con el ejemplo:
Error: javax.faces.FacesException: Cannot get value for expression
Algún componente de JSF no puede acceder al value que hemos indicado de un backing bean
Causas Probables:
Error: Al pinchar en un CommandButton, no hace nada y vuelve a la misma página
Causas Probables:
TomaHawk Error: javax.faces.FacesException: java.io.NotSerializableException:
- Parece que suele suceder cuando un commandbutton vuelve a la misma pagina que lo originó y se debe actualizar otro componente.
Causas Probables:
javax.faces.STATE_SAVING_METHOD client
Pues nada, a ver si os animáis y nos mandáis vuestros errores ;-)
ACTUALIZACIÓN:
Error: java.lang.IllegalStateException: No Factories configured for this Application - typically this is because a context listener is not setup in your web.xml.
A typical config looks like this;
Causas Probables
En los últimos tiempos, estamos en Linking Paths trabajando con Java Server Faces en algunos de nuestros productos (más información en breve). No porque creamos que es el framework definitivo y mejor que todos los demás, sino más bien como una apuesta estratégica de cara al futuro. Pero después de 5+ años haciendo aplicaciones web, digamos que nos plantea tanto dudas como respuestas.
Java Server Faces nos ofrece una serie de ventajas indudables (componentes configurables, la promesa de crear distintos clientes cambiando el renderer, ocultar en parte que es una aplicación web, promover el trabajo con backing beans e IoC, ser un estándar, etc. ), pero a la vez nos de muestra que es un entorno al que aún le faltan un par de vueltas. En mi opinión dos principalmente, aunque algunas decisiones sobre la arquitectura podrían ser discutibles, algo que no voy a hacer porque quiero pensar que las personas que tomaron esas decisiones saben más que yo.
Volviendo a los dos grandes problemas actuales:
- Forma estándar de distribuir y configurar los nuevos componentes.
- Información.
En el primer caso, nos encontramos proyectos como Tomahawk (que pertenece a myfaces) que nos ofrece componentes varios para nuestras aplicaciones (menus paginadores, pestañas, etc.), pero no hay forma sencilla de utilizarlos. Y con sencilla quiero decir: añadirlos al IDE de nuestra elección para poder usarlos con pinchar y arrastar, que es otra de las bondades que se esperan de JSF.
Respecto a la información, me refiero a la situación inherente de toda nueva tecnología. Java Server Faces es nuevo, y como tal la cantidad de información es menor que la disponible para, digamos, Struts. Y no me refiero a libros, sino información de proyectos reales, de los problemas que se han ido encontrando, etc. No puedo evitar tener la sensación de estar en el año 1999 (obviamente mejor situación, en entorno mucho más acotado y mucha más experiencia), en la que todo lo que había era el API de Servlets, y en las que cada uno iba tirando por dónde mejor le parecía (de ahí la variedad de frameworks web en Java).
De modo que, volviendo a la pregunta inicial… ¿está Java Server Faces preparado para un uso real en la empresa?. Obviamente nuestra respuesta es sí. A pesar de esos pequeños drawbacks (y sin entrar en peleas con otros, como Spring Framework o Ruby on Rails), Java Server Faces es una posibilidad más que ha venido para quedarse y con buenas perspectivas de futuro, y nadie que se dedique al desarrollo web en Java debería perderlo de vista (que lo use o no es decisión de cada uno). Sin duda el primero de esos grandes problemas que he comentado lo acabarán solventando, y el segundo… digamos que el segundo se solventa día a día.
Lo que ya ofrece, lo que es seguro que ofrecerá, así como principalmente el hecho de ser un estándar mimado, hacen de Java Server Faces una buena apuesta de futuro con un uso factible hoy.
Por poner nuestro granito de arena, hemos creado una lista de distribución para todos aquellos interesados en Java Server Faces: jsf@dev.linkingpaths.com., así como lo seguiremos impartiendo en nuestros cursos.
Ultimos comentarios
Offshore: ¡nos fuimos a FICOD! | Blog IBCmass - Consultoría de Tecnologías de la información | Web 2.0 | Diseño Multimedia |, Una presentación chula sobre redes sociales, anassé
alberto, Jesus, alberto, Gozque, gimenete, alberto, gimenete, Félix
Nuestro paso por el FICOD 2008 at Linked, » Por la Conferencia Rails 2008, tog: Proyecto Rails del año 2008 | IBCmass - Consultoría de Tecnologías de la información, gestión de contenidos, usabilidad web y web 2.0, Bettina, ecamacho, alberto, VictorR
Cesar Diaz, Jesus Chuda Contreras, Angeles, Ger, Pedro, Alfonso, Windzor, javier, xelha
Emprendizaje Corporativo e Innovación Abierta « redes de innovación @ ikerlan-ik4, aitor, Miguel, Cashflow | externalidades
FICOD 2008 at Linked