Newsgroup: it.comp.www.php
Titolo: get e post

ciao, mi ritrovo uno script dove per passare le variabili uso il metodo get.
Leggendo vari libri sembrerebbe che sia meglio evitarlo per svariate ragioni 
(non ultima è mal digerito dal WC3)
ora io di solito ho usato il post, ma con il post riesco a passare le 
variabili che appartengono ad un campo di input ed io in questo script non 
ho campo di input, (i valori delle variabili mi provengono da una quey ad db 
mysql), inoltre devo avere nella stessa pagina 2 pulsanti di tipo submit, 
che inviano tipi di valori diversi a seconda del pulsante usato.
ora con 2 link differenti associati ai diversi valori del tipo:
link?variabile=valore
riesco na passare all 'altra pagina tranquillamente i predetti valori, 
l'altra pagina li riceve con il metodo get
ma se al posto dei link volessi usare il metodo POST come dovrei fare?
(non uso le sessioni perchè mi danno problemi con i cicli while di una query 
(ovvero mi danno l'ultimo risultato))
in effetti ho fatto uno script che  + o - è cosi
form action=post  pagina.php?variabile=valore
pulsante submit
/form
altro form action=post pagina.php? variabile1=valore1
pulsante submit1
/form
però in questo modo mi sembra di utilizzare una sorta di get, ed in effetti 
se io per ricevere queste variabili nella pagina di destinazione uso un 
$_POST[] le cose non vanno, se uso invece $_GET[] tutto procede regolarmente 
come se avessi passato le variabili con il metodo dei link sopraccitato.
mi date dei suggerimenti  plz, credo di aver letto e fatto abbastanza prove 
per post e get ma qualcosa mi sfugge.
Grazie:) 

 per post e get ma qualcosa mi sfugge.
Premesso che non ci ho capito molto (ma sono anche quasi le otto...)
prova con
<FORM METHOD="post">
<INPUT TYPE="hidden" NAME="miavariabile" VALUE="valore1">
<INPUT TYPE="submit">
</FORM>
in questo modo popoli $_REQUEST[miavariabile] con valore1
e mi sembra anche $_POST[miavariabile]
~omar

 metodo dei link sopraccitato.
Per il semplice fatto che stai usando GET, quando passi valori tramite
query string.
-- 
I am what I am, I do what I can
Do. Or do not. There is not try.

 e mi sembra anche $_POST[miavariabile]
Notice: Undefined constant ...


 Notice: Undefined constant ...
Si', ma io da buon incapace abbatto notice senza pieta'.
Facendo cosi' l'amico si popola $_REQUEST[miavariabile] e ne fa quel che 
vuole .
~omar

 che vuole .
L'utilizzo di $_REQUEST e' sconsigliato poiche' puo' portare a bug
difficilmente tracciabili.


 difficilmente tracciabili.
Eh ma io sono braaaaaaavo ;-)
Scherzo, hai ovviamente ragione sull'attivazione di notice pero' a volte 
se il compromesso non e' grave ci puo' anche stare, poi dipende dai casi...
~omar

 quella notice...
Se non li tieni attivi e' ovvio che la situazione rimarra' sempre la
stessa.


 stessa.
Non mi sono spiegato, io non li tengo attivi perche' se li attivassi su 
una macchina hosting in produzione, PHP mi segnalerebbe *giustamente* 
notice che in diversi casi sono essenziali solo per puristi e paranoici 
(io tra questi...) e al momento non ho bisogno di altri mal di testa.
Discorso diverso farei con warning e cugini...
Solito discorso... a volte la realta' e' diversa dalle rfc e anche a me 
scazza...
~omar

 query string.
immaginavo:P
grazie Astronomy per l'interessamento ed i consigli cmq sempre utili^^
x OMAR grazie anche a te ora fo una ricerca su sto $_REQUEST , non deve 
essere di largo uso , fino ad adesso nelle parti dei libri letti non l'ho 
visto utilizzare molto^^ 

 altri mal di testa.
Il fatto e' che tu hai consigliato tale pratica ad un altro. Se vuoi
consigliare qualche cosa, cerca almeno di consigliare una pratica
corretta.


 passaggio delle variabili all'altra pagina
Stai confrontando le sessioni con i parametri della querystring, sono
cose con comportamenti completamente differenti.


 corretta.
Si' domani...
Io non ho consigliato all'amico di disabilitare notice... ho suggerito 
di usare $_REQUEST, che per il suo caso funziona perfettamente (notice o 
meno....)
A quale pratica di riferisci? Dal tuo quote non ci arrivo...
~omar

 visto utilizzare molto^^ 
Argh! Non farti leggere da Setec ;-)
--
~omar

 A quale pratica di riferisci? Dal tuo quote non ci arrivo...
[ti quoto]
in questo modo popoli $_REQUEST[miavariabile] con valore1
e mi sembra anche $_POST[miavariabile]
[/ti quoto]
Hai suggerito una pratica che solleva dei notice, e poi ti sei
giustificato scrivendo:
[ti quoto]
ma io da buon incapace abbatto notice senza pieta'
[/ti quoto]


 [/ti quoto]
Diavolo... ti cerchero' un link dal manuale della cordialita'...
Il fatto che php ti notifichi la cosa non significa che sia scorretta... 
che cavolo mi rispondi a fare come se avessi scritto una ca$$ata?
Ho suggerito $_REQUEST perche' e' una array che contiene sia $_GET che 
$_POST e nel messaggio dell'amico ci ho letto un problema che poteva 
risolvere cosi'...
Citando... 
http://snipurl.com/kpnn
--
~omar

 Argh! Non farti leggere da Setec ;-)
:P

 Argh! Non farti leggere da Setec ;-)
:P 

 poteva risolvere cosi'...
[mi quoto]
L'utilizzo di $_REQUEST e' sconsigliato poiche' puo' portare a bug
difficilmente tracciabili.
[/mi quoto]


 [/mi quoto]
Nel tuo mondo, nel mio i bug sono tutti tracciabili anche senza notice 
altrimenti si cambia mestiere.
-- 
~omar

 problemi.
Quotalo anche a Giuseppe PHP che di default lo disabilita.
Io penso al succo...
alla forma pensaci tu che hai tempoo.
PS: <Giuseppe PHP> era una battuta... magari nei tuoi algoritmi di 
decodifica dei messaggi oltre alla cordialita' hanno commentato anche 
l'ironia...
-- 
~omar

 notice altrimenti si cambia mestiere.
Si, certo, convinto tu, continua ad usare $_REQUEST e quando inizierai
a vedere comportamente incomprensibili causati da cookie, get e post
con lo stesso nome non venire a chiedere aiuto ...


 con lo stesso nome non venire a chiedere aiuto ...
   ^^^^^^^^^^^^^^^^^^
Insisto col dire che NOTICE aiuta chi ha qualche difficolta' pratica e 
vuole dilettarsi con il purismo del coding (virgolette, avvisi di stare 
attenti... come se uno dormissee... ecc)
Tanto e' vero che *il notice di default e' disabilitato* perche' c'e' 
qualcuno che si rompe le pa$$e a leggere notifiche che puo' benissimo 
ritenere superflue perche' si rende perfettamente conto di quello che 
sta facendo.
Per concludere (spero...)
*E_NOTICE aiuta, ma non e' scorretto non abilitarlo*
Abbiamo raggiunto un accordo accademico adesso o facciamo a gare a chi 
ce l'ha piu' lungo?
-- 
~omar

 chi ce l'ha piu' lungo?
Che cosa? La tua coda di paglia?


 Che cosa? La tua coda di paglia?
ROFTL... avanti un altro...
-- 
~omar
firma in costruzione

 universitari e i loro discepoli.
Davvero? Ed io che pensavo che il php.ini-recommended contenesse i
"recommended php.ini settings". Tralasciando che "We advise you to use
php.ini-recommended, because we optimized the default settings in this
file for performance, and security." Comunque, ovviamente, tu devi aver
ragione visto che vuoi fare "a gare a chi ce l'ha piu' lungo" ...


 ragione visto che vuoi fare "a gare a chi ce l'ha piu' lungo" ...
Facciamo cosi'... ti do un blocchetto di fogli bianchi, tu me lo riempi 
di minchiate sulla programmazione teorica e poi me lo spedisci per Natale.
-- 
~omar
firma in costruzione (ma ci sono quasi...)

 ~omar
Volevo soltanto aggiungere che abilitare i notice non è da paranoici 
come può sembrare, ma anzi oltre a rendere il codice esente da 
qualsivoglia forza di difetto, insegnano molte cose.
Nel tuo caso, ad esempio, scrivendo
$_REQUEST[miavariabile]
il PHP va a cercarsi nel codice la costante "miavariabile" che 
ovviamente non esiste ed è per questo che ti rilascia un notice.
Probabilmente apprezzandone maggiormente l'utilità, si riescono ad 
imparere anche aspetti che nella pratica comune si danno per scontati.
E' sempre cosa buona e giusta per un array associativo specificare 
correttamente la chiave di riferimento tra apici.
Senza ombra di polemica, voleva essere solo un appunto perchè è bene che 
i programmatori PHP che utilizzano il tuo spazio web imparino a 
programmare in PHP senza eccessive approssimazioni, altrimenti quello 
che più ne risente sarà l'amministratore di sistema (che a quanto ho 
capito sei tu) che dovrà ogni giorno tappare buchi qua e la dovuti a 
codice mal scritto.

 codice mal scritto.
Prima di tutto ti ringrazio per aver criticato la mia "usanza" in modo 
cosi' cordiale e costruttivo, e (soprattutto...) cosi' poco di moda su 
usenet.
La mia abitudine a disabilitare E_NOTICE risale a qualche anno fa, 
quando molti prodotti gia' pronti, che diversi miei utenti installavano 
(ricordo ad esempio un primissimo phpPgAdmin o phpbb...), riempivano gli 
schermi di *giustissime* notice... non ti dico le telefonate e i ticket 
aperti...
Oppure, ricordi due o tre anni fa la faccenda di register_globals?
Ho visto gente impazzire per dover riprendere codici pieni di variabili 
del tipo $username
Questo non vuol dire che siano degli incapaci, semplicemente hanno 
preferito scrivere un codice che in quel momento rispettava le *loro* 
esigenze e hanno accettato il compromesso di rinunciare al coding 
accademico.
Comunque alla luce di tutta la diatriba e del tuo messaggio, abilitero' 
E_NOTICE e ne postero' tra qualche tempo i miglioramenti registrati ;-)
Grazie,
cordialmente :-)
--
~omar

 per Natale.
Ti rode davvero tanto, vero?
Stai continuando ad affermare che scrivere codice che solleva notice va
bene perche' tanto tu "da buon incapace abbatti notice senza pieta'".
Poi affermi con tanta sicurezza che *il notice di default e'
disabilitato* e non controlli nemmeno se e' veramente cosi' (di fatto
non lo e' nel php.ini-recommended). Infine dici che il
php.ini-recommended e' un file di configurazione "impostato cosi' per i
professori universitari e i loro discepoli" mentre viene esplicitamente
detto che e' la scelta primaria in quanto file che contiene le
impostazioni necessarie per ottenere performance e sicurezza.
Quello che sembra non aprire gli occhi quando scrive codice sei tu, di
fatto affermi delle cose senza nemmeno prenderti la briga di
verificarle, oltre, ovviamente, a consigliare pratiche scorrette.


 accademico.
Coding accademico? Lo sai il motivo per cui register_globals e' stato
disattivato di default? Ed il motivo per cui e' nella lista delle
rimozioni di PHP6?
Se sei convinto che sia coding accademico pretendere che gli utenti
inizializzino le variabili prima di usarle (pratica che molti altri
linguaggi di programmazione pretendono) allora ti suggerisco di
impostare display_errors ad off, cosi' non avria mai alcun problema di
sorta ed i tuoi script improvvisati non "avranno" mai errori.


 cordialmente :-)
Ciaooooooooooo!
=== 
http://www.negusweb.it
 ===