Newsgroup: it.comp.lang.javascript
Titolo: history.go(-1)

Utilizzo il comando in oggetto dopo una finestra di alert, con il seguente
codice:
<script>
alert('Il valore di data inserito non è valido');
history.go(-1);
</script>
In pratica, dopo la compilazione di un form, controllo con php il formato
della data, e se è sbagliato rispedisco indietro.
il problema è che in un paio di pc (con IE, come tutti gli altri), il
ritorno cancella anche tutti i dati inseriti nel form, e fa ripartire da 0.
in particolare, uno dei due pc ha win 98 e l'ultimissima versione di IE con
tutte le ultimissime patch, ma non funziona.
Se non fosse abilitato il javascript, non visualizzerebbe nemmeno la
finestra di alert, quindi è qualcos'altro che non va.
Scrivendo history.back() potrei risolvere?
Grazie, Cristiano

 della data, e se è sbagliato rispedisco indietro.
E' perche' deleghi al client?
Con tutte le piattaforme HW/SW ed i browser che ci sono in giro non puoi 
sperare che sia l'unico caso particolare.
Se c'e' qualcosa di sbagliato riproponi il form (nella pagina di 
arrivo!) con precompilati i campi Ok segnalando quelli sbagliati.
E continua a riproporre il form finche' non e' tutto Ok.
Se e' un "utente" prima o poi riesce a compilare perfettamente.
Se e' un "utonto" si scoccia e tanto di guadagnato per te :-)
-- 
Ciao, Riccardo
------------------------------------------------------------------------
http://www.jsdir.com
  ---- Bring Your Site To Life!!!!
http://www.wmtools.it
 ---- WebMasterTools - Servizi per il tuo sito
http://www.dev2dev.it
 ---- La rete ha connesso nuove particelle - D2D006
------------------------------------------------------------------------
Per rispondere: togli i PUNTO .

 ovviamente serverside come gia` fai (never trust user data).
Sottoscrivo. I controlli Javascript servono per guidare e aiutare l'utente
PRIMA dell'effettivo post dei dati; per evitare tempi di attesa e inutili
richieste al server (che senso ha far controllare a PHP una form di login
con i campi nulli? ), ma i controlli su quest'ultimo devo SEMPRE essere
fatti.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

 CYT

Ma se hai a disposizione un linguaggio come php,
ti conviene memorizzare tutte le variabili del form
in una sessione, indipendentemente su che pagine stai,
quando ritorni sul form richiami i dati di sessione e il gioco
è fatto, la procedura è semplicissima.

 e uno medio-alto
" Scegli il modulo piu' adatto a te: 
<a href=''>Normale per normali</a> - <a href=''>Banale per utonti</a> " 
Non e' mica una cattiva idea! :-P


 nessuno contesta la facilità quanto la opportunità.
No, il suo discorso e' validissimo, tranne che per una piccola cosa.
Difatti, e' lato server che si dovrebbe fare questo genere di cose, non
certo lato client.
Come gia' detto, non si puo' sapere che tipo di impostazioni puo' avere il
client o il S.O.. e' troppo empirica la cosa.
L'unico appunto e' che non c'e' alcun bisogno di nessuna sessione; del
resto i dati inviati si trovano gia' nell'header http, e ormai tutti i
linguaggi server side li salvano direttamente in array/collection ($_POST
per PHP, Request.Form in ASP, per esempio); quindi, non occupi affatto
altra memoria.
Basta gestire opportunamente la pagina che riceve il POST della form, per
avere l'output desiderato.


 certo lato client.
Certo , se poi occorrono degli errori e l'utente è tosto , il server
continuerà logorroicamente a rispedire e a ricaricare le
pagine,semplicemente onde far constatare all'utente che ha sbagliato a
scrivere una data; e allora javascript lo si usa per hobby.
Mi sembra pratica anti buona programmazione.
Bye.

 scrivere una data;
Mi chiedo se stiamo parlando dello stesso thread.
Non si parlava di controlli lato client o lato server, si parlava di
*riproporre* nella form i valori inseriti dall'utente.
In questo contesto, usare l'history e' quanto piu' di "anti buona
programmazione" esista.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"Questa e' una lezione difficile, ma importante: Cio' che e' stato, e cio'
che sara', non cambia cio' che e'.
Sta a te decidere poi come prendere questa cosa,se logorarsi per un passato
che non puoi cambiare, invece di prendere tutto il bene che il presente ti
offre." ()

 altra memoria.
I dati tramite gli header vanno per l' appunto inviati e sono validi solo
sulla pagina ricevente, non sono riutilizzabili sul documento di partenza,
a parte che l' array non venga memorizzato sul filesystem,
nel database o il metodo più sensato è appunto proprio una sessione.
Rispondo anche a Post precedente,
non bisogna essere dei maghi per effettuare i determinati controlli,
basta del codice ben congeniato che controlla gli errori da parte dell'
utente
per fare cio' basta una sola  funzione che accetta dei flag
questo un esempio di codice
tratto da un mio sito dove il form contiene 32 elementi
 function error_msg($value, $FLAG=''){
 switch($FLAG){
case NO_ERR:
if ($value==false){echo  "questo non è un campo obbligatorio";}
             else {echo "$value" ;}
             break;
case NIC:
if ($value==false){static $x = 0; $x++;
                   echo  "<a href=\"javascript:history.back()\" >Back
$x</a>" ;} //ERROR
             else { echo "$value" ;} //OK
              break;
case PASS:
if (strlen($value)< 5){static $x = 0; $x++;
                   echo  "<a href=\"javascript:history.back()\">Back $x</a>"
;} //ERROR
             else { echo ereg_replace("[[:alnum:]]","*",$value) ;} //OK
              break;
case EMAIL:
......
case CAP:
......
case COUNT:
..... e cosi via
}
}
quindi invocando la funzione
error_msg($_POST['password'], PASS)
il controllo viene effettuato solo sulla pass,  il Flag COUNT  traccia la
somma degli errori, il Flag EMAIL........
in caso si verifica un' errore mi viene proposto l' history.back()
A questo punto sulla pagina che contiene il form c' è
un' altra funzione (solo una) che si occupa di prendere i dati dell' array
POST
precedentemente salvati in sessione, per riempire i campi
e segnala all' utente i vari  errori, indipendemente dalle pagine visitate,
quando
torni sul quel form i fields vengono sempre riempiti
Ciao
Jeey

 ..... e cosi via
Ma in questo modo perdi i vantaggi che i linguaggi server-side ti offrono,
e invece acquisisci i difetti di quelli client-side.
I tuoi sono controlli di tipo formale. Questo genere di controlli va fatto
a monte, in javascript, PRIMA di inviare i dati al server.
Che senso fare una richiesta al server, se sto inviando una login e
password vuoti? E' una richiesta inutile, spreco risorse e calcoli da parte
del server. Questo genere di controlli, possono essere fatti client side,
prima del post.
Un controllo finale, prima dell'INSERT in un DB, ad esempio, andrebbe fatto
in ogni caso, ovviamente (mai fidarsi dell'utente), ma e' inutile fare "n"
richieste di pagina al server per sentirsi dire che si e' compilato male un
campo.
Il discorso e' un altro. Una volta che il server riceve la pagina, e magari
ci sono errori di tipo logico o relazionale, non formale, (es. provo ad
inserire nel DB un valore gia' presente in un campo che deve avere valore
univoco), allora "trappo" l'errore, lo notifico all'utente, e gli
ripresento la form precedente con i valori che aveva inserito, magari
posizionandolo sul campo errato, e colorandolo differentemente.
Il tutto, da PHP (o qualsiasi linguaggio server side), senza apppoggiarsi
all'history.back() che, al di la' del fatto che JS potrebbe anche essere
disattivato (da qui il discorso di ricontrollare cmq i dati inviati prima
del inserimento, a meno che JS non sia un prerequisito), il back e'
farlocco e dipende TROPPO dalla configurazione utente, ovvero dal tipo di
browser che ha, dalle impostazioni che ha, e se si trova o meno dietro
proxy o quant'altro.
Inoltre, il semplice back da JS, non ti permette modificare la pagina
d'inserimento, per dare un feedback maggiore all'utente, e guidarlo in modo
piu' accurato.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"Questa e' una lezione difficile, ma importante: Cio' che e' stato, e cio'


 posizionandolo sul campo errato, e colorandolo differentemente.
Giusto, la mia funzione serve per fare un' anteprima della pagina, prima che
i dati vengono immessi, qualcuno puo' aver sbagliato a scrivere qualcosa
Forse siamo tutti e due un po' OT perchč la domanda era un' altra :-)

 Forse siamo tutti e due un po' OT perchč la domanda era un' altra :-)
Non mi pare di essere OT. La domanda era inerente al riproporre i dati nel
form dal quale si proviene, sottlineando che l'history.back talvolta
funziona, talvolta no.
La risposta all'utente e' stata data da piu' persone, ovvero: Usa PHP per
ripopolare i campi, non affidarti all'history che e' un metodo empirico,
dipende da troppi fattori.
Cosa che ho detto anch'io nei miei post.


 programmazione" esista.
a titolo di curiosità vi faccio sapere che il net ha questa funzione
implementata nel framework e svolge tutto in automatico.
Bye

 implementata nel framework e svolge tutto in automatico.
A parte che stavamo parlando di PHP.. :)
Il framework .NET per quanto riguarda il web lascia ancora a desiderare.
Ne riparliamo con l'imminente versione 2; allo stato attuale e'
indicatissimo per le intranet aziendali windows based. Non per il web. Il
codice che genera e' pesante e non conforme agli standard W3C.
Quando mi tocca usarlo per il web, cerco di limitare il piu' possibile
"l'autogestione" da parte del framework.
Recentemente per lavoro, ho visto pagine web crescere da 19kb a 73kb solo
per colpa del viewstate e dell'approccio ".NET oriented".
Senza dimenticare che l'IDE "eredita" i difetti di FrontPage.. secondo me
se eliminassero il "design view" farebbero una cosa buona e giusta.
Se per caso sbagli a visualizzare del codice HTML in "Design" ecco che
l'IDE interviene e ti inserisce in modo del tutto arbitrario del codice,
laddove "lui pensa" che sia "giusto" inserirlo.
Questo ha dato un po' di grattacapi ad un'azienda a cui abbiamo dato in
outsourcing un progetto.. c'era un filmato flash che a volte andava, a
volte no. Solo perche' l'IDE aggiungeva un attributo che, se trovato in
connubio con un altro, mandava in crisi il plug in di Flash.
Io preferisco che il compito di "pensare" sia lasciato allo sviluppature, e
non al tool che usa.
-- 
C'ya,
  ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,



Una cosa che mi incuriosisce, e non poco, come manterresti te i valori
dell' array POST o GET negli Header passando da una pagina all' altra
senza serializzarli, non considerando minimamente cio' che ho descritto io,
forse mi č sfuggito qualcosa nonostate ho letto tutto il thread.
Mi interessa soprattutto perchč io non conosco altri metodi :-O
Ciao :-)

 forse mi è sfuggito qualcosa nonostate ho letto tutto il thread.
Ti sfugge il senso della seguente frase:
"Basta gestire opportunamente la pagina che riceve il POST della form, per
avere l'output desiderato."
Il tutto e' incentrato sulle metodologie ed organizzazione modulare degli
applicativi/website.
Tenendo a mente qual'e' l'output desiderato, e gestendo opportunatamente la
pagina che riceve il POST della form, e' possibile infatti saltare il
passaggio di "passare da una pagina all'altra", almeno a livello client,
cosa tra l'altro sconsigliatissima. Introduci piu' possibilita' di errore,
e piu' passaggi per l'utente.
I metodi per ottenere cio', sono molteplici. Dalla gestione a moduli, come
dicevo (e quindi require/include), al copiare le informazioni dell'header
HTTP relativo ai POST della pagina ricevente, a quello della pagina di
output, e cosi' via.


 a parlarmi di "buona programmazione" :-)
Bye

 caso tutt'altro che raro di browser o supporto javascript carenti.
scusa la contraddizione abissale ma se ritieni javascript non all'altezza
non mi sembra il caso che lo usi e non lo usi, sprechi tempo per niente , lo
fai lato server e basta.
e poi non riesco a capire francamente come fai a far poggiare le basi
grafiche del tuo sito su javascript.
cut>
cut

 grafiche del tuo sito su javascript.
Non del "suo" sito.


 ha messo l'accento, sprechi dei byte
Ti ha fatto dei chiari esempi Marco, per questo genere di cose. Stiamo
parlando sempre di "validazione".


 BASARE la validita' dei campi.
ok terrò in conto questa ipotesi peò penso , che se si è coerenti lo si è
fino in fondo.
o lo usi o non lo usi.
tanto vale che fai tutto lato server e basta.


 --
cut

fino in fondo. o lo usi o non lo usi.tanto vale che fai tutto lato server e basta.
Hai una pagina per farti inviare un messaggio dagli utenti del sito
web, non usi il mailto, ma uno script sul sever per l'invio di mail
via SMTP. Il form e' qualcosa del tipo:
<html>
<head>
</head>
<body>
<form name="contattaci"  action="
http://www.sito.com/sendmail.php
"
method="post">
 <label for="to">Messaggio a:</label> 
 <select name="to">
 <option selected value="
in...@sito.com
">Informazioni</option>
 <option selected value="
ord...@sito.com
">Ordini</option>
 <option selected value="
webm...@sito.com
">Web Master</option>
 </select><br>
 <label for="from">Il tuo e-mail:</label><br>
 <input type="text" size="50" name="from"><br>
 <label for="messaggio">Il tuo messaggio:</label><br>
 <textarea id="messaggio" cols="60" rows="15">
 </textarea><br>
 <input type="submit" value="Invia">
</form>
</body>
</html>
Al massimo hai inserito un javascript che ti valida il campo from per
verificare che sia veramente un indirizzo di posta. Sullo script lato
server non fai alcuna validazione dei dati.
Domanda:
Supponiamo che uno spammer individui il tuo sito e provi a vedere se
fai oppure no le validazioni lato server (basta provare :-)), quanto
tempo ci vuole allo spammer per inviare 100000 SPAM in giro per il
mondo usando lo script sul tuo server e facendoti passare per
colpevole di spamming?
'bye

 tanto vale che fai tutto lato server e basta.
No, perche' cosi' non approfitto del "valore aggiunto" fornito da
Javascript.
Ti ribadisco il concetto: Un conto e' sfruttarlo per averne dei vantaggi a
livello di feedback utente, un conto e' usarla per basarci sopra la
validazione dei dati.


 chiedo in cambio (e senza che nessuno se ne sia mai lagnato).
Idem, e sinceramente non capisco dove voglia andare a parare Antonio.


lasciarli fare.
Un conto e' "mettere delle trappole" sapendo bene che non ci saranno
problemi per te ma solo per gli hackers, un altro e' avere una falla
di sicurezza e sapere di averla ma limitarsi a dire "beh, tanto il
bastardo lo becco comunque".
'bye

 tant'è che tutti gli hackerini sono stati bene o male tutti sgamati.
Si certo, come no. Vorrai dire quei bambinetti di 14 anni che si divertono
a lurkare le ML di exploit per poi fare "copy&paste" di vari .vbs da
distribuire in rete, forse.


 idee sono come le palle ed ognuno ha le sue) non va bene, spiacente.
E poi mi si viene a parlare di pratiche "anti buona programmazione"..


 'bye

 Marcia impostura

 o si usa o non si usa.
No, questo e' un discorso insensato. Siamo informatici,ma non per questo
dobbiamo pensare solo in formato binario, no? Sarebbe troppo semplicistico.


 server , la fai via server e basta.
No, perche' cosi' perdi i vantaggi offerti da JS per *guidare* l'utente e
dargli un giusto *feedback*, senza contare di evitare inutili richieste al
server. Ma non si deve affidare la *validazione* (ripeto, la VALIDAZIONE)
*unicamente* a JS.


 sintassi con l'analisi del problema).
Gia'. Fortunatamente, non e' il caso dell'azienda per cui lavoro. La'
l'unico problema e' la "base storica" con la quale abbiamo a che fare.
Ma a livello di tecnologie, sono abbastanza aperti.. Non come vorrei, ma ho
lavorato in posti peggiori (partner Microsoft, ad esempio.. per loro
prodotti diversi da M$ semplicemente non esistono).


 sarebbero un cattivo esempio di programmazione... mah!
Gia', in effetti e' un po paradossale.


 dobbiamo pensare solo in formato binario, no? Sarebbe troppo
semplicistico.
Francamente Zero lo trovo qualcosa di poco intelligente, questo è un mio
mero punto di vista, scusa se mi sposto col parallelo.
Se devo parcheggiare la macchina , o lo faccio io o lo fa mio padre, non ha
senso che prima la parcheggia lui e poi la riparcheggio io , subito
dopo.L'effetto è lo stesso e io ho fatto un operazione in più inutile.
La vedo una cosa inutile e stupida. Tutto qua il senso del mio topic, per
piacere non estremizziamo le cose.


 La vedo una cosa inutile e stupida.
Quella di far parcheggiare tua padre prima, e te successivamente? Sicuro.
Almeno quanto affidare a JS la validazione dei dati in modo esclusivo.
La validazione *deve* essere sempre fatta lato server. Lato client, e'
opzionale. E' preferibile farla *ANCHE* lato client perche' in questo modo,
chi ha JS abilitato e quindi ne ha la possibilita', puo' usufruire di
questo vantaggio, e puo' essere guidato in modo intuitivo ed in tempo
reale, senza essere necessariamente connesso al server.
Questo su web, ti ripeto. In ambienti ristretti e controllati, come
intranet, il discorso cambia parzialmente. Ma rimane sempre il discorso di
"non fidarsi" dei dai inviati dall'utente.


 Tralascia entrambi, ed al piu` potrai andare a lavorare a Redmond :-)
ROTFL :D


 server , la fai via server e basta.
Lato server e' indispensabile a te per non farti rubare tutto il db, 
cancellare tabelle, etc.
Lato client e' utile:
- all'utente che ha un feedback immediato e se corregge risparmia tempo
  (il web va ancora in analogico/isdn, alto che banda larga);
- a te che quantomeno hai risparmiato un po' di lavoro al server.
Possiamo vederli un po' di questi siti?
-- 
Ciao, Riccardo
------------------------------------------------------------------------
http://www.jsdir.com
  ---- Bring Your Site To Life!!!!
http://www.wmtools.it
 ---- WebMasterTools - Servizi per il tuo sito
http://www.dev2dev.it
 ---- La rete ha connesso nuove particelle - D2D006
------------------------------------------------------------------------
Per rispondere: togli i PUNTO .

 Idem, e sinceramente non capisco dove voglia andare a parare Antonio.
Mah, secondo me e' un amico di quel "max" di qualche giorno fa... se non 
e' proprio lui.
La stessa capoccia dura e lo stesso stridìo di unghie sugli specchi :-)
