Perché utilizzare un tag form quando invii tramite ajax?

Domanda filosofica:

Supponiamo che io abbia un’applicazione web che richiede javascript e un browser moderno, quindi il miglioramento progressivo non è un problema. Se il mio modulo viene creato tramite javascript e gli aggiornamenti dei miei dati vengono eseguiti tramite POST e PUT ajax, c’è davvero qualche motivo per includere i miei controlli in un tag form? Se continuerò a usare il tag, per ragioni semantiche o strutturali, c’è qualche ragione per avere parametri di azione e metodo che ignorerò? Mi sembra una presa da un’era precedente a me.

Esiste almeno un’importante funzione di esperienza utente fornita specificamente dal wrapping degli input all’interno di un tag form:

Il tasto invio invierà il modulo. Infatti, in Safari per dispositivi mobili, è così che compare il pulsante “Vai” sulla tastiera .

Senza un modulo che avvolge gli input, non c’è nulla da presentare.

Ovviamente è ansible fornire il comportamento della chiave di accesso tramite un evento keypress, ma non so se questo funziona per i dispositivi mobili. Non so voi, ma preferirei lavorare con la semantica fornita dal browser piuttosto che imitarli con gli eventi.

Nel tuo caso, onsubmit semplicemente un onsubmit eventi onsubmit per il modulo, che invierà il tuo AJAX, quindi return false , annullando l’invio effettivo.

Puoi semplicemente fornire action="" (che significa “self”), e il method non è richiesto – il valore predefinito è GET .

Se non hai bisogno di miglioramenti progressivi, in teoria non ne hai bisogno.

D’altra parte, le form hanno alcuni fantastici raggruppamenti e effetti semantici . Usandoli, puoi raggruppare gli elementi del modulo in modo logico e rendere più facile per i tuoi script raccogliere i valori di determinati elementi.

Ad esempio, se vuoi inviare ajax l’input dell’utente, è sempre più facile dire: “prendiamo tutti gli elementi in questo modulo e inviali” piuttosto che “prendiamo questo input, questi due selezioniamo e questi tre textareas e li inviamo “. Nella mia esperienza, in realtà aiuta lo sviluppatore se sono presenti tag di form .

AJAX è eccezionale, ma come ha affermato JamWaffles (+1 a lui), l’utilizzo dei tag form fornisce un metodo di fallback.

Personalmente uso i tag dei moduli, anche per le cose che invio con AJAX perché è sintatticamente chiaro e semplifica l’acquisizione di tutti gli input all’interno di un modulo specifico. Sì, potresti farlo con un div o qualsiasi altra cosa ma, come ho detto, usare un modulo è sintatticamente bello.

Per inciso, i lettori di schermo trattano il contenuto all’interno di un form modo diverso quindi ci sono problemi di accessibilità da prendere in considerazione in qualsiasi modo si scelga di andare. Tieni presente che prove aneddotiche suggeriscono che Google considera l’accessibilità nelle sue classifiche, quindi se il SEO è un problema per te, utilizza un modulo e fallo correttamente.

Riepilogo: moduli OK per MVC, semplici app Web, pessime per le applicazioni web ricche di componenti e ricche.

Motivo: i moduli non possono annidare altre forms: grande limitazione per un’architettura orientata ai componenti.

Dettagli: per le tipiche applicazioni MVC, le forms sono eccezionali. Nelle applicazioni web complesse e ricche che utilizzano molti javascript e AJAX e con molti componenti qua e là, non mi piacciono i moduli. Motivo: i moduli non possono annidare altre forms. Quindi se ciascun componente esegue il rendering di un modulo, i componenti non possono nidificarsi a vicenda. Peccato. Modificando tutti i moduli in div, posso nidificarli e ogni volta che voglio prendere tutti i parametri per passarli a Ajax, faccio solo (con jQuery):

$ ( “# Id_of_my_div”) trovare ( “[nome]”) serialize ()..;

(o qualche altro filtro)

invece di:

$ ( “# Id_of_my_form”) serialize ().;

Anche se, per ragioni sentimentali e semantiche, continuo a nominare le mie dive qualcosa_form quando agiscono come forms.

Non che io possa vedere. Attualmente sto sviluppando un’applicazione web che utilizza

s, ma li sto utilizzando in modo da avere un metodo di fallback se l’utente ha disabilitato JavaScript (un e.preventDefault interrompe normalmente la registrazione del modulo). Per la tua situazione, dove stai dicendo che l’utente DEVE avere JavaScript, un tag

non è necessario, ma potrebbe essere un’idea tenerlo comunque nel caso in cui il browser debba fare qualcosa con esso, o accedervi come una specie di class.

In breve, no, non è necessario usare

se si sta facendo AJAX puro, anche se lasciarlo dentro potrebbe essere un’idea se improvvisamente deciderai di creare un codice di fallback in futuro.

Secondo me: se lo usi per ragioni semantiche, usalo come previsto. L’attributo action è richiesto (può anche essere lasciato vuoto) per essere ben formato, inoltre puoi separare i tuoi URI dalla tua logica js, impostando l’attributo action e leggendolo prima della chiamata ajax.

Non vedo perché dovresti usare il tag form qui. L’unico motivo per utilizzare un tag del modulo (diverso da quello per ottenere il markup per la convalida) è se si desidera che l’utente “invii” i dati utilizzando un input sumby o un tag button. Se non hai bisogno di farlo, allora non c’è bisogno del modulo. Tuttavia, non sono sicuro se sarà considerato markup “valido”. Se lo si utilizza, è sufficiente eseguire

poiché l’azione è l’unico attributo obbligatorio del tag form. Tuttavia, fai apparire un buon punto, il futuro delle applicazioni web probabilmente non avrà più bisogno del modulo e della metodologia di invio tradizionale. Molto interessante e mi rende felice. hehe 🙂