xmlHttpRequest + Form = Aaaarrrggg!
Mucho cuidado con modificar el contenido de un formulario desde xmlHttpRequest. Ayer perdí casi 4 horas tratando de investigar por qué no funcionaba usandolo desde Firefox, Netscape y Mozilla. Explorer no me daba problemas.
El error era “document.formulario has no properties” (o algo similar). Pero el formulario ahi estaba!!!, y los campos actualizados estaban perfectamente sentados dentro de <form> y </form>... que es lo que pasa!!??
Bueno, pues resulta que el <form> estaba definido entre un <table> y el primer <tr>, cosa que no es correcta según el DOM. Yo tenía esa costumbre (maña?) para evitar esos extraños espacios en blanco antes y después del formulario.
Por que entonces al cargar la página todo funcionaba bien, pero en el segundo “click” todo se venía abajo??
Bueno, al cargar la página con estructura “no-estandar”, el browser lo interpretaba como un documento html normal (mal estructurado), y por ende el comportamiento era adecuado a ese esquema. Pero el DOM no perdona, y al modificar la estructura del formulario, los campos se llenaban en un formulario “inexistente” para el DOM. Por lo tanto al decirle “document.formulario.tal.cosa()” el sistema me decía… “cual formulario??, aqui no hay nada!”.
Moralejas.-
a) Escribe html válido.
b) Si todo parece estar bien, pero no funciona… date una vuelta por el validador de tu confianza. La estructura (mal formada) puede darte pistas acerca de lo que está fallando.
c) Golpear el escritorio no ayuda en nada, por el contrario… puede empeorar las cosas.
Saludos!!!
11 Comentarios
RSS de los comentarios de esta entrada.
Deja un comentario
Disculpa, los comentarios están cerrados.

y si se la miento al explorer??? XD
Comment por jesusbet — Mar 1, 2005 @ 12:20 am
Ja ja ja, te juro que no serás el primero…
Solo que en este caso, el “maleducado” parser del Explorer fué más consecuente con mi estupidez. Firefox y los “Chicos Buenos” no me la perdonaron y me hicieron sufrir algunas horas.
Comment por Manolo — Mar 1, 2005 @ 1:21 am
Para evitar los espacios:
form {display: inline;}Pero he leído que es semánticamente correcto meter formularios en tablas, le guste o no a Mozilla.
Comment por mark — Mar 1, 2005 @ 2:52 am
Si es correcto meter formularios en tablas. El problema es meterlo como lo hice yo, en un lugar sin sentido…
<table>
<form> < --- Entre table y tr no debería haber nada
<tr>
<td>Bla Bla</td>
...
</></form></table>
Comment por Manolo — Mar 1, 2005 @ 9:58 am
Yo hace tiempo descubrí una forma muy util de organizar los formularios.
Puedes usar la etiqueta
Labelpara contener los inputs…
un elemento de bloque más con el cual trabajar… asi no necesitas tablas y es más semántico.<label for="input">Etiqueta:
<input type="text" id="input" name="input"/>
</input></label>
Tal vez esto los sabía todo mundo pero yo apenas lo descubrí.
Comment por sosa — Mar 1, 2005 @ 10:08 am
Que tal tueressosa!!
Fijate que de hecho yo casi siempre uso el “label”, a veces para dar formato y otras simplemente para efectos de usabilidad. Pero esta es una de esas construcciones de formulario en donde algunas filas tienen 7 u 8 inputs, otras uno solo, otras dos selects, otras combinaciones de radio y select… en fin, nada facil para acomodar con floats, clears, widths y heights…
Mientras no sea soportado el
display:table, table-row, etc...en todos los navegadores en uso, creo que en estos casos será inevitable usar tablas para lograr un acomodo mas o menos decente.Saludos!
Comment por Manolo — Mar 1, 2005 @ 10:25 am
Por la descripción que haces del formulario, la agrupación más lógica sería usando Fieldsets y no tablas. A parte de ser semánticamente correctos, sería más fácil realizar cambios en el formulario a posteriori.
ciao
Comment por DrSlump — Mar 1, 2005 @ 12:44 pm
Aprendiendo de los maestros
:D
Comment por pedro — Mar 1, 2005 @ 12:53 pm
El problema no es la mala costumbre de escribir el “form” entre el “table” y el “tr” (mala costumbre que aún tengo). El problema es la mala costumbre de usar TABLAS!
Comment por cvander — Mar 1, 2005 @ 1:03 pm
Dr Slump:
Tienes mucha razón. Hay muchos “elementos-estandar” que permitirían realizar esta clase de tareas. Es solo cuestión de quitarse las malas costumbres (10 años de html “mal hecho” en mi caso). Verás que en mi próximo proyecto con formularios me meteré a intentarlo con los fieldsets (que no he usado nunca).
Christian:
Tienes razón. Aunque no hay que olvidar que las tablas existen por una razón. El otro día hablaba con un amigo que quería hacer una lista de alimnos, materias y calificaciones usando DIVs SPANs y CSS. Deberías de ver la cantidad de problemas en los que se metió... Cuando en realidad ESE es un uso justificado para las tablas. No debemos usar tablas para layout, pero la información tabular (entiendase datos en filas y columnas) DEBE meterse en tablas para su facil navegación, y por definición.
Saludos!!
Comment por Manolo — Mar 1, 2005 @ 1:21 pm
Sobre el comentario de Sosa
Seguramente ya lo sabrás pero de todas formas, por si le sirve a alguien, decir que cuando el elemento input está dentro de un label no hace falta usar el atributo for.
y sobre el uso de tablas para el layout,
En mi opinión es tan poco semántico el usar tablas para hacer las columnas del layout como el hacerlo con floated divs. Hasta que no llegue CSS3 no hay ningún método especifico para las columnas. Si me apuran diría incluso que para columnas de un mismo alto las tablas son una opción semánticamente más correcta.
También decir por eso, que en muchas ocasiones es preferible el usar floated divs o técnicas similares, para así poder ofrecer un código html más fácil de leer cuando no hay estilos asociados, como por ejemplo cuando queremos que el contenido de la columna ‘derecha’ sea el primero en mostrarse.
ciao
Comment por DrSlump — Mar 1, 2005 @ 3:54 pm