Submit di un form a più riprese...

[james]

Ho scritto uno script in php che gestisce un form, non fa nulla di eccezionale, semplicemente nella pagina che riceve i dati in POST del form, fa i controlli del caso e se qualcosa non va bene, tipo un campo obbligatorio lasciato vuoto, ecc, semplicemente rigenera il codice HTML del form già compilato con i dati immessi dall'utente segnalando gli errori...tutto perfetto se non fosse stato per la necessità di caricare più file...

Seguendo questo approccio, al submit verrebbero caricati tutti i file, con una grande attesa (diversi MB), e se qualcosa non passa la validazione il sistema mi rigenera il form ma chiaramente i file andrebbero uppati di nuovo...pensavo quindi di affidarmi a jquery per fare un upload legato all'evento onchange dei vari campi file, tipo su gmail, così che quando si seleziona ogni file intanto parte l'upload con la progessbar per ogni file, elimino il submit del form per evitare che lutente faccia il submit prima che gli upload sono terminati altrimenti mi si bloccano e poi rimetto il submit solo dopo che ho la conferma che tutti i file sono caricati, quindi quando ricompare il submit i file sarebbero già uplodati ed il form segue la vita di sempre, se ci sono errori in validazione ripropongo il form con il riferimento dei nomi dei file caricati, tipo quando su gmail si caricano allegati, intanto parte l upload poi l'utente finisce di scrivere la mail, che ne pensate? Esistono strade più efficienti? Pensavo di affidarmi a formdata per creare in jquery tutti caricamenti ajax e a caricamento completo sostituire il codice nel codice HTML del form degli input file con un hidden che contiene il riferimento al file caricato per ripescarlo in caso di errore di compilazione...che ne pensate?

[cavicchiandrea]

Se ho capito bene che hai un form di registrazione dati che inoltre uploda diversi file di grosse dimensioni, io separerei le due cose primo step registrazione dati, poi upload per questo step in rete trovi script già pronti anche con upload multipli di grosse dimensioni e cross browser.
Separando le operazioni ritengo tu abbia una migliore gestione e meno problemi.

[james]

Originariamente inviato da cavicchiandrea
Se ho capito bene che hai un form di registrazione dati che inoltre uploda diversi file di grosse dimensioni, io separerei le due cose primo step registrazione dati, poi upload per questo step in rete trovi script già pronti anche con upload multipli di grosse dimensioni e cross browser.
Separando le operazioni ritengo tu abbia una migliore gestione e meno problemi.

Strada che non posso percorrere, ad ogni file devo associare comunque due campi di testo, a dire il vero una è una select e l'altro un text, ed entrambi sono obbligatori, per cui anche separando i file dal resto dei campi non ad essi collegati, mi ritrovo cmq sempre un form contenente sia file che input text, per cui devo per forza fare il submit di questi dati insieme ma senza dover far ricaricare il file all'utonto se dovesse dimenticare di compilare i campi obbligatori. Se moltiplichiamo questo problema per i 4 file da caricare, in totale ho 8 campi (4 select e 4 input text) che l'utonto devo compilare e che sono relativi ai file (a parte tutti gli altri), per cui posso separare una parte ma il problema resta tale e quale...un po' come se su gmail occorresse prima scrivere il testo, oggetto, destinatari poi per allegare qualcosa sia obbligatorio passare da un'altra parte, sarebbe anche scomodo per l'utente.

[cavicchiandrea]

Originariamente inviato da james
Strada che non posso percorrere, ad ogni file devo associare comunque due campi di testo, a dire il vero una è una select e l'altro un text, ed entrambi sono obbligatori, per cui anche separando i file dal resto dei campi non ad essi collegati, mi ritrovo cmq sempre un form contenente sia file che input text, per cui devo per forza fare il submit di questi dati insieme ma senza dover far ricaricare il file all'utonto se dovesse dimenticare di compilare i campi obbligatori. Se moltiplichiamo questo problema per i 4 file da caricare, in totale ho 8 campi (4 select e 4 input text) che l'utonto devo compilare e che sono relativi ai file (a parte tutti gli altri), per cui posso separare una parte ma il problema resta tale e quale...un po' come se su gmail occorresse prima scrivere il testo, oggetto, destinatari poi per allegare qualcosa sia obbligatorio passare da un'altra parte, sarebbe anche scomodo per l'utente.

In tal caso ritengo le due strade più plausibili:
A) Uplod multiplo delle immagini prima eseguo upload di tutte le immagini per avere un controllo degli upload unico nella pagina/step successiva/o associo alle immagini la select il testo
B) Eseguo singoli upload immagine select testo, ripetendo tale processo per tutte le volte che mi occorre
L'opzione C ritengo che sia come fai adesso che non funziona (bene o come vorresti), e integrare ajax quando c'è dimezzo degli upload non è facile (sopratutto di grosse dimensioni).
L'esempio di gmail lo trovo fuori luogo, non sempre puoi replicare certe funzioni perché certi portali hanno programmatori, risorse, tecnologia più avanzate del libero professionista programmatore, in oltre va tenuto in considerazione risultato finale costi.
Comunque auguri per il lavoro

[Enzaccio]

Allora, se anch' io comincio a capisciare bene, la strada più efficiente rimane quella di far eseguire lato client (JavaScript) i controlli di validazione sugli input e sulle select.
Questo può avvenire all' ONCHANGE (per le SELECT) e all' ONKEYUP (per le textbox), cioè all' istante di selezione/compilazione una per una: se c'è un' incongruenza, il messaggio intimidatorio appare subito; oppure all' ONSUBMIT del FORM per tutti i campi e se c'è un' incongruenza l' invio non parte e compare l' avviso.

Rimane il fatto che JavaScript è un settore che può trovarsi disabilitato su un alcuni browser, cioè alcuni utenti intenzionalmente navigano con JS disabilitato (o qualcuno glielo ha disabilitato sul navigatore e nell' ignoranza, così vanno avanti).
In tal caso si ricade nella situazione di partenza per cui, devesi comunque mantenere una strategia lato server seppur meno agile.
Si può anche obbligare all' invio solo tramite JS: in tal caso il bottone diverrà un TYPE="Button" in luogo di un TYPE="Submit". A chi tiene JS disabilitato non gli parte niente.

[carlomarx]

Originariamente inviato da Enzaccio
Rimane il fatto che JavaScript è un settore che può trovarsi disabilitato su un alcuni browser, cioè alcuni utenti intenzionalmente navigano con JS disabilitato (o qualcuno glielo ha disabilitato sul navigatore e nell' ignoranza, così vanno avanti).
In tal caso si ricade nella situazione di partenza per cui, devesi comunque mantenere una strategia lato server seppur meno agile.

Dividiti le strade. Costruisciti una base solida lato server, meno agile, che funzioni comunque anche con JS disabilitato. Dopodiché costruisciti anche un framework in JS per gestire il tutto in maniera più dinamica con chi ha JS abilitato.
Ti consiglio la lettura di questi articoli:

• https://developer.mozilla.org/en-US/...ploading_files
• https://developer.mozilla.org/en-US/...b/API/FormData
• https://developer.mozilla.org/en-US/...API/FileReader

Originariamente inviato da Enzaccio
Si può anche obbligare all' invio solo tramite JS: in tal caso il bottone diverrà un TYPE="Button" in luogo di un TYPE="Submit". A chi tiene JS disabilitato non gli parte niente.

A "chi tiene JS disabilitato" partirà comunque un submit quando preme invio

[Enzaccio]

Originariamente inviato da carlomarx
A "chi tiene JS disabilitato" partirà comunque un submit quando preme invio

Eh ma io mica cambio solo il pulsante ... il PHP attende anche una var JS-powered che se JS non è attivo, non gli arriva e ri-partorisce il FORM di conseguenza; ripetenendo il consueto: "Avete JavaScript disabilitato sul Navigatore e l' operazione non può ecc. ecc. " che appare già in partenza.

Opportuna osservazione, comunque.

function tiMando(){
 //... bla bla
 document.form.trappola.value='ok';
 document.form.submit();
 }

 <input name="trappola" type="hidden">

document.form. etc. is obsolete a way, though.

[Enzaccio]

Comunque, a sostegno della necessità qua condivisa di mantenere comunque controlli lato server, c'è anche il fatto che qualcuno con medie competenze di HTML e anche poche di PHP, qualcuno che ti vuole male, può farsi un form suo e impestarti il database di unuseful stuff.

Dal codice sorgente del tuo form, custui/ei/oro vedono i NAME da riprodurre.

Si potrebbe fare appello a delle sessioni, se ci sono, aperte; o all' indirizzo di provenienza del form. Ma io preferisco sempre mantenere i basilari controlli lato server.

AJAX invece, benchè fratello gemello di JS non l' ho sulla punta delle dita e lascio parlare altri più pratici. Condivido tuttavia il sentore di Andrea.