phpdev-expert / uda

Automatically exported from code.google.com/p/uda
Other
0 stars 0 forks source link

Grid + formulario de busqueda (Sin maint) #76

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
UDA -->Tenemos una aplicación en UDA y tenemos una página que contiene un 
grid y un panel de búsqueda. Es similar a un mantenimiento creado por los 
wizards pero no queremos mantenimiento. La cuestión es que queremos poder 
buscar y hacer uso del método de búsqueda del grid pasándole los parámetros 
de búsqueda. Hacemos lo siguiente para enviarle los parámetros de búsqueda 
pero no entra al método getAll.

Se adjunto archivo con el código que utilizamos.

Original issue reported on code.google.com by serg...@gmail.com on 8 Mar 2012 at 9:24

GoogleCodeExporter commented 9 years ago
Una vez analizados los problemas las conclusiones a las que se ha llegado son 
las siguientes:

- El error que se produce en la página no es debido al código javaScript 
utilizado sino a la naturaleza de los datos enviados y a los tipos de datos de 
los campos del objeto receptor.

La llamada "$(this).rup_grid("reloadGrid");" funciona correctamente. La llamada 
que produce dicha ejecución es : 
http://www.des.ejgv.jaso/m05jParqueMovilReservaWar/validarsolicitudes?_search=fa
lse&nd=1320670493872&rows=10&page=1&sidx=fechaSolicitud100&sord=desc&estado102=T
ODAS&fechaSolicitud100=&fechaIni100=&fechaFin100=&dni101=&nombreApellidos101=&ac
cion=&codigoSolicitud=&motivoRechazo=

El problema que tiene realmente esa pagina, que hace que dicha llamada devuelva 
un error 500, es el tipo de datos que espera recibir, y no recibe, el 
controlador. Si se prueba a colocar dicha llamad en el FireFox, la respuesta 
del servidor será un error 500. Si se le quita a dicha llamada los campos 
relacionados con las fechas, 
http://www.des.ejgv.jaso/m05jParqueMovilReservaWar/validarsolicitudes?_search=fa
lse&nd=1320670493872&rows=10&page=1&sidx=fechaSolicitud100&sord=desc&estado102=T
ODAS&dni101=&nombreApellidos101=&accion=&codigoSolicitud=&motivoRechazo=, la 
respuesta será un JSon vació no un error 500. Si hacemos alguna prueba mas y 
mandamos alguna consulta con que devuelva datos, 
http://www.des.ejgv.jaso/m05jParqueMovilReservaWar/validarsolicitudes?_search=fa
lse&nd=1320670493872&rows=10&page=1&sidx=fechaSolicitud100&sord=desc&dni101=1628
0710&destino102=DESTINO%204, los datos devueltos son los apropiados.

El problema que tiene la aplicación depende, directamente, de la conversión 
de datos que procede del navegador con los datos esperados por el controlador. 
No se han podido hacer pruebas directas del error, pero se ha observado que el 
controlador que decepciona la llamada se ha especificado que los tipos fechas 
se mapeen en campos de tipo "Timestamp". Dentro de la clase (bean) que moldea 
el objeto de los datos enviados desde el navegador, se ha apreciado que se ha 
utilizado la anotación "@JsonSerialize(using = JsonDateSerializer.class)" que 
hace que "Jackson" convierta los datos entrantes en objetos tipo "Date". Como 
se puede apreciar a simple vista, las clases no concuerden por lo que, 
seguramente, se esta dando el error descrito en la m53. 

Para solucionar el problema, es necesaria la modificación de la aplicación 
para que se gestionen correctamente las fechas. Desde el grupo de consultoría, 
para resolver el problema, se recomienda el uso, tanto en el controlador como 
en la clase (bean) representante del  modelo, del tipo "Date". Con este cambio 
debería resolverse el problema.

Original comment by serg...@gmail.com on 8 Mar 2012 at 9:24