¿Por qué utilizar una etiqueta de formulario cuando se envía mediante ajax?

Question

cuestión filosófica:

Di Tengo una aplicación web que requiere javascript y un navegador moderno, mejora de manera progresiva no es un problema. Si mi formulario está siendo creado a través de javascript, y mis actualizaciones de datos se realizan a través de ajax POSTs & PUT, ¿hay realmente alguna razón para ajustar mis controles en una etiqueta de formulario? Si todavía voy a usar la etiqueta, por razones semánticas o estructurales, ¿hay alguna razón para tener parámetros de acción y método que voy a ignorar? Se siente como una retención de una era anterior para mí.

Answer 1

Hay al menos una característica importante de experiencia de usuario disponga específicamente envolviendo entradas dentro de una etiqueta de formulario:

La tecla enter presentará el formulario. De hecho, en Mobile Safari, así es como obtienes el botón "Ir"to appear on the keyboard.

Sin un formulario que envuelva las entradas, no hay nada que enviar.

Puede, por supuesto, proporcionar un comportamiento de tecla enter a través de un evento de pulsación de tecla, pero no sé si esto funciona para dispositivos móviles. No sé ustedes, pero prefiero trabajar con la semántica proporcionada por el navegador que tener que imitarlos con eventos.

En su caso, simplemente proporcionaría un controlador de eventos onsubmit para el formulario, que haría su envío AJAX, luego return false, cancelando la entrega real.

Simplemente puede proporcionar action="" (que significa "yo"), y method no es obligatorio — el valor predeterminado es GET.

Answer 2

No veo por qué tendrías que usar la etiqueta del formulario aquí. La única razón para usar una etiqueta de formulario (que no sea para obtener su marcado para validar) es si va a hacer que el usuario "envíe" los datos usando una entrada de sumbit o una etiqueta de botón. Si no necesita hacer eso, entonces no hay necesidad del formulario. Sin embargo, no estoy seguro si se considerará marcado "válido". Si lo usa, puede simplemente hacer <form action=""> ya que la acción es el único atributo requerido de la etiqueta del formulario. Sin embargo, si menciona un buen punto, el futuro de las aplicaciones web probablemente ya no necesitará el formulario y la metodología de envío tradicional. Muy interesante, y me hace feliz. jeje :)

Answer 3

No es que yo pueda ver. Actualmente estoy compilando una aplicación web que usa <form> s, pero las estoy usando así que tengo un método alternativo si el usuario tiene JavaScript desactivado (un e.preventDefault detiene la publicación del formulario normalmente). Para su situación, cuando dice que el usuario DEBE tener JavaScript, no es necesaria una etiqueta <form>, pero podría ser una idea guardarla de todos modos en caso de que el navegador necesite hacer algo con ella, o para acceder a ella como una especie de clase.

En resumen, no, no necesita usar <form> si está haciendo AJAX puro, aunque dejarlo en una idea puede ser una decisión si de repente decide crear un código alternativo en el futuro.

Answer 4

En mi opinión: si lo usa por razones semánticas, entonces úselo como está previsto. El atributo de acción es necesario (también se puede dejar vacío) para estar bien formado, también puede separar sus URI-s de su lógica js, estableciendo el atributo de acción y leyéndola antes de la llamada ajax.

Answer 5

AJAX es genial, pero como JamWaffles (+1 a él) dijo, el uso de etiquetas form proporciona un método alternativo.

Personalmente utilizo etiquetas de formulario, incluso para las cosas que envío con AJAX, ya que es sintácticamente clara y hace que sea fácil de agarrar todas las entradas dentro de una forma específica. Sí, puedes hacer esto con un div o lo que sea, pero como dije, usar un formulario es sintácticamente agradable.

Incidentalmente, los lectores de pantalla tratan el contenido dentro de un form de manera diferente, por lo que hay problemas de accesibilidad para considerar de cualquier forma que elija ir. Tenga en cuenta que la evidencia anecdótica sugiere que Google considera la accesibilidad en sus clasificaciones, por lo que si SEO es una preocupación para usted, utilice un formulario y hágalo bien.

Answer 6

Si no necesita una mejora progresiva, en teoría no las necesita.

Por otro lado, form s tiene algunos efectos geniales de agrupamiento y efectos semánticos. Utilizándolos, puede agrupar sus elementos de formulario lógicamente, y hacer que sea más fácil para sus scripts reunir los valores de ciertos elementos.

Por ejemplo, si desea ajax-enviar alguna entrada del usuario, siempre es más fácil decir: "tomemos todos los elementos en esta forma y envíenos" que decir "tomemos esta entrada, estos dos selects y estos tres textareas y envíalos ". En mi experiencia, realmente ayuda al desarrollador si hay etiquetas form.

Answer 7

Resumen: formularios OK para MVC, aplicaciones web sencillas, malas para aplicaciones web ricas orientadas a componentes.

Motivo: formas no pueden anidar otras formas: gran limitación para una arquitectura orientada a componentes.

Detalles: Para las aplicaciones típicas de MVC, las formas son geniales. En aplicaciones web ricas y complejas que usan mucho JavaScript y AJAX y con muchos componentes aquí y allá, no me gustan los formularios. Motivo: las formas no pueden anidar otras formas. Luego, si cada componente representa un formulario, los componentes no pueden anidarse entre sí. Demasiado. Al cambiar todas las formas a divs, puedo anidarlos, y cada vez que quiero tomar todos los parámetros para pasarlos a ajax, simplemente lo hago (con jQuery):

$ ("# id_of_my_div"). Find ("[nombre]"). serialize();

(o algún otro filtrado)

en lugar de:

$ ("# id_of_my_form") serializar();.

Aunque, por razones sentimentales y semánticas, sigo nombrando mis divs something_form cuando están actuando como formas.