Y tu... le presentas al usuario mensajes de error claros y contextualizados?

Pues no sigo una metodologia tan estricta, tal vez por que estoy traumado por el performance o no se, pero en el cliente solo hago validaciones simples.
En el bean de negocios es donde tengo las validaciones mas comunes, como que un usuario no este repetido, si se relaciona una entidad a otra no existente, si se quiere actualizar el importe de una deuda ya saldada, etc. Además que estan los constrainst en la bd para no perder la integridad.

Esta manera me ha dado muy buenos resultados, si el usuario ve un mensaje de error de error no entendible después de realizar una acción, significa que se me esta pasando una verificación en mi bean de negocios por lo tanto la agrego. Fácil, entendible y simple.

PD. ¿por que todos los ejemplos van relacionados con aplicaciones web?

Pues... por que para mi desdicha... es en lo que estoy programando ahorita... y en lo que parece que a la mayoria de los clientes le gustan ahorita las aplicaciones (solo hay que ver las capacidades para programacion web, y "no web" en Java, para darse cuenta de cual fue la prioridad de Sun durante los ultimos 10 años... (una pista: Web) ).

P.D. Pero por ejemplo, la imagen de indicadores de error en tabla (y de hecho la otra también, pero de esa si hay ejemplos web),no pude encontrar un ejemplo de algo asi en una aplicacion web (deberia existir, pero encontre a nadie capas de hacerlo, asi que esa es una foto de una aplicacion "no web")

Lo que mas me gusta de esta metodologia, es que en el JSON viene la informacion de que tabla y que campo tuvo que error, y dicha informacion puede utilizarse para marcar de forma precisa el campo que tuvo el error inclusive se pueden usar las muy rudimentarias facilidades de control de foco del navegador para enviar el foco al (primer) campo con error, algo que mas de un usuario me ha pedido. ¿Como consiguen ustedes esa funcionalidad?

Me encantaria si alguien me dijera que conoce algun lugar de donde se pueda descargar un componete opensource para swing que haga lo mismo que el ErrorProvider de .NET

No es lo mismo decir "en el en el cliente solo hago validaciones simples", a decir "a las validaciones simples solo las hago en el cliente". Lo primero es correcto (siempre que también hagas dichas validaciones en el servidor)... lo segundo (que implica que no las haces en el servidor)... abre la puerta a que te hackeen. A cual de las 2 te referias exactamente?

Parezco disco rayado. Pero esta página muestra cómo validar entradas del usuario en Tapestry 5. La validación se hace de inmediato en el cliente, con AJAX (T5 incluye Prototype) y nuevamente en el servidor al recibir la petición. Puedes poner validaciones simples como que un campo no se puede quedar en blanco, o que debe ser numérico dentro de un rango, o que sea un email válido, o una expresión regular, una fecha en el pasado (o en el futuro), etc.
Para validaciones de integridad y cosas así, pues no se va a saber qué pasa hasta que se intente guardar datos, en ese caso es cosa de que el error (por ejemplo una excepción) traiga un mensaje útil al usuario para que la página de Tapestry agregue el mensaje a los errores de la forma y se le presente en la página, con el mismo formato que los errores que ya maneja de manera automática.

Actualmente la versión 5.1 trae sus propias anotaciones para validación, lo cual es un rollo si por ejemplo usas la validación de Hibernate; tuve que hacer para una aplicación un convertidor dinámico que detecta anotaciones de Hibernate Validation y le agrega a esos métodos (los getters de beans de dominio) las anotaciones equivalentes de validación de Tapestry.

Pero para la versión 5.2 ya anunciaron que van a usar el estándar nuevo de Java (que no usaban antes porque no existía), y Hibernate ya dijo lo mismo, de modo que ahora en Hibernate podrás usar las anotaciones JSR-303 y se van a validar en Tapestry cuando edites directamente un bean de dominio en una forma.

Mmmm, cada ves me convenzo mas de que tal ves deberia usar Tapestry... por otro lado, yo también parezco disco rayado: Que hay del foco? Tapestry ya maneja lo de colocar el foco en el primer campo con error automáticamente? o si, por ejemplo, quiero integrar el manejo de error con mensajes tipo growl, que tan facil o dificil es integrar algo como jGrowl con Tapestry?

Del JSR-303.... no estoy seguro de estar convencido de que deberas vaya a ayudar... los ejemplos que he visto en internet todos se quedan en el nivel de validar a nivel booleano si el campo es "valido o invalido" y por lo tanto generan mensajes del tipo "El valor esta repetido" o "El valor es erroneo" y no llegan a ser capaces de presentar mensajes del tipo "El nombre Juan esta repetido" o "El valor “2009/13+13” para fecha de nacimiento no es válido, por debería tener el formato: “AAAA/MM/DD” '". Igualmente, los ejemplos que me he encontrado no cubren casos en los que se necesita consultar a la base de datos para verificar que las cosas esten correctas (como registros repetidos, restricicones derivdas del estado de otras tablas (como no aprobar pedido si no se ha hecho el deposito, o no permitir 2 juntas a la misma hora en el mismo salon). Inclusive tiene problemas para representar validaciones relativamente simples como que la "fecha de matrimonio" no puede ser anterior a la "fecha de nacimiento" (presentando por supuesto, los nombres de lo 2 campos y valores en el mensaje)

No recuerdo si Tapestry te pone en el primer campo con error, casi podría apostar que lo hace. No he visto jGrowl, pero tendrías que ver una demo del manejo de errores de Tapestry; digamos que estás en un campo que espera un valor entre 0 y 100 y le pones 500, al dar tab (como es el estándar jajaj) para cambiar de campo, aparece una burbuja sobre el campo que abandonaste, indicando algo como "debes teclear un valor entre 0 y 100" (Puedes personalizar los mensajes de error). Si intentas submit a la forma no te deja por ese error. Si desactivas JavaScript y le das submit de todas formas, te regresa a la misma página y te aparece al principio de la forma un recuadro con todos los errores que contiene.

JSR-303 me parece que trae algo adicional para validación cross-field (cuando los valores de un campo dependen de otro campo, como lo de fecha de matrimonio y de nacimiento), pero evidentemente no manejan reglas de integridad, eso lo seguirás haciendo tú en tu aplicación, pero ya es menos chamba, no? No pretende ser una panacea de validaciones, pero pues para validaciones simples creo que va a simplificar la chamba porque en conjunto con un validador en Swing o JSF o Tapestry o Struts o lo que uses, ya te dejas de preocupar de ese manejo de errores.

Lo de formato de fechas no sé si lo contempla JSR-303 pero T5 actualmente sí valida el formato de fechas y me parece que le puedes dar un rango de fechas válidas (para que en fecha de nacimiento nadie ponga algo antes de 1910 por ejemplo).

Aquí puedes bajar algunos demos para que lo veas en acción.

No he visto jGrowl, pero tendrías que ver una demo del manejo de errores de Tapestry;

No se ve mal el manejo de errores de Tapestry (aunque siendo sincero, con JSF/Richfaces/Seam se pueden conseguir aproximadamente el mismo efecto). La cuestion es que cuando te piden hacer algo que JSF/Richfaces/Seam no hace "de fabrica" el esfuerzo es demasiado grande... Hay que: Implementar tu annotation en Java, ponersela a tu POJO, ajustar tus componentes JSF (la parte mas dolorosa), implementar una logica espejo en javascript para dar sensacion de velocidad (si es que aplica), etc, etc.

¿Que tan facil (o dificil) es implementar este tipo de extensiones a la validacion con Tapestry?

Mientras tanto, en el mundo de los programadores Jaxer, se puede implementar la validacion sin violar DRY. Como me da tristeza que no lo hayan implementado sobre Rhino... Ese seria un proyecto de tesis interesante, migrar Jaxer a Rhino y poder hacer esto:

Como el "runat" esta en both, esta funcion javascript se invocara de forma transparente tanto en el cliente como en el servidor, asi que si la usas para validar datos, puedes estar seguro de que el usuario no podra "darle la vuelta"

En la liga que mandé de input validation en Tapestry, lee esa sección. No sé si es a lo que te refieres con extenderla. Puedes extender la clase AbstractValidator de Tapestry para implementar validaciones que no se incluyan, que son Required, Max, Min, MaxLength, MinLength, Email y Regexp.

La sección "customizing validation messages" también es útil. Ya viste que son validaciones en campos; las puedes hacer muy sofisticadas usando expresiones regulares. Aparte puedes convertir entre cadenas y otros tipos (como fecha por ejemplo) usando FieldTranslators (sección "overriding the translator with events").

En la liga que mandé de input validation en Tapestry, lee esa sección. No sé si es a lo que te refieres con extenderla.

Por lo que me dices, esta el AbstractValidator de Tapestry para implementar validaciones que no se incluyan, pero, lo que me pregunto, es de que modo puedes amarrar las validaciones ya existentes(u otras nuevas) con algún modo de presentación especifico. En otras palabras, lo que preocupa es la integracion de comportamiento nuevo no solo por la parte de Java, si no tambien por la parte de JavaScript

Ejemplo: Mi usuario quiere que los mensajes de error le aparezcan con jGrowl o con jQuery Dialog o alguna otra apariencia personalizada... que habria que hacer? que tan latoso resulta? que facilitades te da Tapestry para poderte comunicar con javascript? Maneja Tapestry un API Javascript para facilitar la vida a la hora de crear componentes con uso intensivo de javascript? o supon que quiero "disparar" un comportamiento en el cliente, personalizado, solo necesario para una pantalla... me provee Tapestry con algún API javascript que me permita "reaccionar" y saber que hubo un error de validación y llamara a una funcion javascript en consecuencia?

Por ejemplo, veo aqui, que Tapestry usa Blackbird para ayudarte a depurar interacciones javascript, no conocia Blackbird, pero se ve excelente! Se puede decir que Tapestry se integra bien por el lado de logging con Javascript, pero me gustaría saber si también lo hace en otros sentidos (por ejemplo, si yo quisiera integrar un mecanismo de logging diferente de Blackbird... seria muy dificil?)... Se que puedo averiguar al respecto googleando, pero me gustaria conocer la opinon al respecto de alguien que ya lo haya intentado ...

El soporte de AJAX en Tapestry, hasta donde yo he visto, consiste en cosas como lo siguiente:

• Puedes preguntarle al objeto Request si es parcial o completa (parcial es una petición de XmlHttpRequest, completa pues es normal del navegador). Esto te sirve dentro de métodos de tu página que pueden ser invocados en ambos casos.
• Puedes implementar métodos que devuelven estructuras JSON (Tapestry trae clases para manejar estructuras JSON aunque no es necesario que las manejes directamente) e invocarlos desde Javascript (T5 trae incluido Prototype pero por supuesto puedes usar jQuery si lo prefieres o alguna otra cosa).
• La manera en que Tapestry recibe parámetros en sus peticiones se presta bien para invocaciones parciales desde Javascript. No me lo sé de memoria bien pero por ejemplo si quieres invocar el método   en la página   y pasarle el nombre "juan", el URL es algo como ; el método   lo puedes implementar como   y dentro del método puedes invocar   para saber si estás respondiendo a una petición AJAX o a una normal (si es que te interesa hacer cosas distintas en uno u otro caso). Tapestry codifica la lista como JSON y la devuelve para que la puedas parsear en el Javascript que hizo la invocación.

Ah y cómo obtienes la petición? En tu clase con IoC:

Tapestry trae una cosa que se llaman mixins, uno que viene incluido es para autocompletar cosas, ya sabes el típico que tecleas algo en un campo de texto y te aparecen opciones; lo puedes tener en una forma sin teclear una sola línea de Javascript.

Otra cosa que usa AJAX y que puedes usar sin teclear nada de JS es lo de actualizar regiones de una página. En mi blog puse algo de eso.

No sé si sea fácil sustituir Blackbird por otra cosa. Antes no había nada y ahora trae Blackbird, que es una maravilla porque te aparece la ventana con un como stacktrace de Javascript, y trae incluso algo de info de lo que pasó en el server, etc. así que no he visto cómo quitarlo o sustituirlo porque para empezar no sé si haya otra cosa similar y segundo, está muy bueno el blackbird pero tampoco creas que lo he usado a fondo; me ha servido mucho para ver los errores y me ayuda a resolverlos por la info que me despliega, pero pues trae como hasta una línea de comando la cual no tengo idea cómo usar (no he tenido la necesidad).

La pregunta no iba orientada tanto al uso de Blackbird, mas bien a los "integration hook" que posiblemente tenga Tapestry para poder hacer callbacks hacia JavaScript y reportar su estado (lo que permitiria integrarlo con Javascript de poderosas e interesantes maneras)

Puedes implementar métodos que devuelven estructuras JSON (Tapestry trae clases para manejar estructuras JSON aunque no es necesario que las manejes directamente) e invocarlos desde Javascript (T5 trae incluido Prototype pero por supuesto puedes usar jQuery si lo prefieres o alguna otra cosa).

Se parecen muchismo a las de json-simple, excepto por una (en mi opinon importante) carencia por parte de Tapestry, las clases equivalente de de json-simple implementan las interfaces de java Collections. Es decir, en mi opinión,   deberia implementar   y   deberia implementar  , el que en las clases equivalentes (y practicamente con el mismo nombre y API) en json-simple si implementen esas interfaces, las hace mucho mas facil de manipular (por ejemplo si lo requiero, puedo pasarle un JSONObject a NamedParameterJdbcTemplate.queryForList

La manera en que Tapestry recibe parámetros en sus peticiones se presta bien para invocaciones parciales desde Javascript. No me lo sé de memoria bien pero por ejemplo si quieres invocar el método buscar en la página Persona y pasarle el nombre "juan", el URL es algo como ;

Eso suena muy muy interesante, eso significa que puedo acceder al API de mis componentes mediante URLs pero al mismo tiempo puedo binder esa API con elementos de formas? como una fusion entre DWR y JSF... suena muy poderoso, tendre que hecharle una mirada a fondo :-)

Otra cosa que usa AJAX y que puedes usar sin teclear nada de JS es lo de actualizar regiones de una página. En mi blog puse algo de eso.

Si, eso es comodo, tambien existe en JSF+RichFaces, el problema es que con interfaces complejas llegue rapidamente al limite de lo que se puede hacer con regiones de refrescado (al menos en Richfaces, este es un caso mas de "fundido de foco", las regiones de refrescado construyen nodos del DOM de la pagina, y si te toca la mala suerte de que el nodo reconstruido es el que iba a recibir el foco, pues el foco se pierde (RF-7706)... los refrescados de Tapestry si conservan el foco? otro problema era cuando tenia que refrescar una región dentro de un componente que aparecía mas de 1 ves en una pagina, Richfaces simplemente se confundia y refrescaba siempre a la instancia del componente que encontraba primero (RF-7706)... Tapestry no sufre de eso?).

Debido a ese y otras limitaciones con el refrescado por region para interfaces con interacciones complejas, prefiero hacer yo mismo mis refrescados con javascript. pidiendo JSON del servidor... definitivamente tengo que averiguar mas de ese aspecto de Tapestry...

La primera vez que hice un refrescado parcial de una página, dentro de un ciclo, me topé con lo que dices; se refrescaba el primer elemento en vez del que debía ser. Pero le di la vuelta, no me acuerdo ahorita ni cómo... pero puedes revisar la página de detalle de pregunta en el proyecto de JavaMexico 2.0, ahí es donde le di la vuelta a ese rollo. Bueno realmente lo importante creo que está en un componente reutilizable, que es una liga para poner contenido, condicional a que estés registrado en la página. Es decir si un visitante ve la página, la liga dice "Regístrese para contestar" por ejemplo, mientras que a un usuario ya registrado le aparece "Contestar esta pregunta"; en el primer caso, al activar la liga, aparece un pequeño panel de login pidiendo usuario y password y si pones bien tus datos, se sustituye por el campo de texto para agregar respuesta. En el segundo caso, se sustituye la liga directamente por el campo de texto para contestar. El componente se puede reutilizar en otras páginas, se le indica el texto que debe aparecer al usuario ya registrado, el texto al visitante, y el componente de hecho rodea el contenido que debe aparecer cuando un usuario registrado activa la liga.

Me referia a eso, a que en el cliente solo hago validaciones simples del tipo: que el email escrito en un campo sea realmente un email, que la longitud de una cadena tenga una cantidad de caracteres como minimo, a que se obligue a capturar un campo.. etc.

Y para aplicaciones swing, existen unas librerias para validaciones llamadas jgoodies (en realiad son todo un conjunto de librerias para facilitar la programcion en swing, que en lo personal encuentro bastante utiles, al menos la de forms y looks). Y aparte existe el framework basado en spring llamado spring rich client platform, que esta muy bien pensando y tiene todo un enfoque para realizar validaciones en las forms. No hace validaciones verificando la info en la base de datos, sin embargo ofrece una muy buena manera de retroalimentación al usuario para cosas simples, como las que mencione arriba.

Realmente la única diferencia entre tener un sistema basado en web y otro en el escritorio, es que para el segundo se necesita instalar la java virtual machine, y que para estos tiempos ya casi todo mundo tiene, es como una obligacion junto con flash.

saludos

Realmente la única diferencia entre tener un sistema basado en web y otro en el escritorio, es que para el segundo se necesita instalar la java virtual machine

No opino lo mismo (y algunos otros tampoco)... aquí una discusión al respecto.

En cuanto a validaciones para swing, jGoodies está muy bonito pero no es software libre, ni es un estándar tampoco. Lo bonito del JSR-303 es que permitirá usar exactamente las mismas anotaciones. Si programas un objeto de dominio (digamos la entidad Usuario), le pones anotaciones de JSR303 y ya será cosa de los frameworks procesarlas: Tapestry en web (o ICEFaces o quien sea; la idea es que un framework de web decente deberá procesar esas anotaciones de alguna forma), Hibernate al momento de persistir, y en Swing pues ya será jGoodies o algún otro framework quien procese estas anotaciones durante la captura.

Me referia a eso, a que en el cliente solo hago validaciones simples del tipo: que el email escrito en un campo sea realmente un email, que la longitud de una cadena tenga una cantidad de caracteres como minimo, a que se obligue a capturar un campo.. etc.

Y todas ellas, las vuelves a validar en el servidor?

Y el caso del fundido de foco? RF-6039. Si, por ejemplo, tengo 2 controles, digamos un input textbox y un select combobox y:
en "onblur" del textbox tengo que resfrecar al combobox, pero ademas el combobox es el elemento que recibe el foco cuando este abandona al textbox... en richfaces, lo que ocurre es que como el refrescado destruye al combobox y lo crea otra ves, el foco se pierde... que ocurre en Tapestry?

Desconozco lo que pase en ese caso con Tapestry. Pero pues probablemente lo mismo; hay manera de darle la vuelta el whateverFaces? Se puede solucionar por ejemplo en una app con JSP solito aunque sea mucha talacha? o es bronca del navegador o de la spec de HTML/Javascript/loquesea?

excelente respuesta, para mi que es problema de la computacion, por no hacer los focos multifuncionales y perfectos jajaj

mas bien de la computacion web... si no fuera por el html y los browsers todo seria perfeccion y armonia con los focos ;-) (Ciertamente no dan problemas en Swing, o en SWT, o en WPF, o en GTK+ o en Motif o en Win32 o en...)

Al parecer, este problema de fundido de foco, es derivado de hacer AJAX con frameworks que funcionan "por recreacion de fragmentos the interfaz".

Si te pones a pensarlo, en una aplicacion tradicional, de escritorio, cuando quieres cambiar el texto de un inputtext, o de combobox, no quitas al inputtext y pones otro. Lo que haces es asignarle el valor que quieres ver al input text. Pero en AJAX por refrescado, quitas al elemento del DOM y pones uno nuevo. Seria como si en Swing en vez de hacer esto:

Hicieramos esto:

Parece de locos no? Pues en Web con AJAX por refrescado... es lo normal!

En Richfaces, el modo de darle la vuelta es mantener una variable global en el cliente (en javascript) que recuerde el "Id" del elemento que tenia el foco antes del ultimo proceso de recreacion de UI, y luego, cuando el proceso AJAX a terminado, asignarle el foco al nuevo elemento (que ahora tiene el Id del destruido).

Yo diria que es una bronca del modo como se hacen los refrescamientos AJAX... son demasiado burdos (e ineficientes), tumban todo un inputtext cuando podrian hacer un diff y solo cambiar el value (que es lo que esta diferente) en ves de cambiar todo el control (e imaginate si ademas ese control ya tiene conectados diferentes eventos, o personalizada su apariencia, todo eso hay que volverlo a hacer en cada recreacion)... eso hace que las aplicaciones AJAX programadas a base de javascript siempre sean mas eficientes que las basadas en refrescado (imaginate cuando lidias con una tabla editable, hay que reconstruir toda la tabla, en ves de solo "bindearla" con el nuevo conjunto de datos).

Todos los frameworks de AJAX quitan el elemento y lo sustituyen por otro? Yo recuerdo haber hecho alguna vez a patín una función en javascript que refrescaba las opciones de un combo según lo que seleccionas en otro combo, y lo que hacía era quitar todos los elementos del combo y volverlo a llenar, pero no lo quitaba y ponía otro... no creo que ningún framework AJAX haga lo mismo...

Bueno, es un hecho que RichFaces lo hace... la pregunta es... lo hace Tapestry? No lo se, lo que se, es que los framewoks basados en Javascript (ExtJs, YUI, Spry, jQuery, etc) no lo hacen (bueno, en realidad no es que no lo hagan, es que como se hace de un modo mas "manual" es inmediatamente obvio para el desarrollador que tumbar todo no seria lo mas conveniente) y que Richfaces me hizo pasar un trago amargo por esta peculiaridad... por eso te preguntaba sobre la influencia del refresh de Tapestry en el foco quiero saber si es un problema unico de Richfaces, o si es mas bien un error comun a las frameworks que implementan Ajax por refrescado (como Tapestry, JSF 2.0, Richfaces, ICEFaces, ASP.NET, etc, etc).

En realidad queria dar a entender de que es mucho mejor hacer un sistema de escritorio que uno web. Creo que no se notó la ironía del asunto.

así es, y luego las valida la base de datos (bueno no todas, como por ejemplo la del email no se podria).
El asunto es mantener la integridad de la información, no? ahora la pregunta mas bien es: en que momento informarle al usuario de que está violando una regla. Yo prefiero que la validación la haga mi bean de negocio, por si existen varios clientes, no estar preocupandome si le agregue tal cosa o no.

sobres

Estoy de acuerdo con lo de hacer la validacion con el bean de negocio (claro que no siempre se puede, por que a veces en donde trabajas a algunos les gustan mas los stored procedures) lo que si es que es mejor validar en una capa baja, precisamente por por si existen varios clientes, para no estar preocupándonos si le agregue tal cosa o no. Pero ahi es donde entra la pregunta.... ¿Como reportas tu tus errores desde el Bean? Lanzas una excepcion? Manejas un objeto "contexto de error"? manejas un Map con los errores por Bean? En que momento validas? Cuando cambia la propiedad? con insertas al objeto en el UnitOfWork? Cuando haces commit de la transaccion? Como preparas a tus widgets the Swing para que reciban informacion de tus beans?

lo de manejar un contexto de errores se me afigura a que tu bean de negocios primero hará los checks, por cada fallido lo agregas a tu contexto y antes de iniciar con el update checas, si hay errores pues no inicias y retornas tu contexto de error.

Bueno, sinceramente no creo que esto tenga mucho impacto, el chiste es notificar al usuario con un error entendible no? Yo acostumbro en mi beans de negocios tener 2 procesos en un mismo metodo, primero realizo todas las verificaciones, si falla alguna lanza una excepción. En mi cliente cacho esa excepción y muestro un dialogo de error con el mensaje de la excepción. Si la llamada en el cliente se hizo desde un dialogo, la excepcion se cacha antes de cerrar el dialogo para que el usuario pueda modificar solo los errores. Y la segunda es el procedimiento, que en este punto no deben existir errores así que cualquier commit deberia funcionar. Claro que no todo es perfecto, tal vez se me estan pasando checks en el bean que la base de datos si tiene, y el usuario veria un mensaje no entendible, pero bueno nadie es perfecto, solamente agrego el check al bean cuando se necesite.

Y otro caso mas extremo que se da en ocaciones muy aisladas es cuando por ejemplo, tu objeto de dominio debe tener por ejemplo una relacion de pagos que en total sumen un importe y no se debe pasar. Si dos usuarios dan clic al mismo tiempo en pagar, el sistema no deberia crear los dos movimientos. Eso yo lo soluciono conel versioning, pero ese tipo de errores ni como detectarlos y a fuerzas el usuario verá un mensaje no muy claro. Pero bueno, todo sea por mantener la integridad de los datos.

sobres