Volledige versie bekijken : html post types I.C.M php
supermaggel
%Europe/Berlin %927 %2005, 23:16
hoi iedereen, ik heb een vervelend probleem :P .
ik weet dat ik een chaos coder ben, en ik design liever dan coden, maargoed.
ik heb een probleem met de POST/GET methodes van een html form. het hele html form wordt gemaakt in php, dus vanaf <form action="...." ~ </form> en alles wat erinzit.
nou heb ik in dit form als action: SID.php?query=searchitem method: GET.
in het form zitten maar 3 dingen, een pulldown lijst (<Select> en <Option>) een textbox (input type=text) en een submit knop. de eerste twee onderdelen hebben een naam, de pulldown heet "inputitemtype" en de textbox heet "inputitemname".
in de phpcode die verder volgt, wil ik in hetzelfde php document, als er op de submit knop gedrukt wordt, de 3 variabelen terughalen: van het pulldown lijstje, de textbox, en de form action. dit doe ik als volgt:
$searched_item_name = $_GET["inputitemname"];
$searched_item_type = $_GET["inputitemtype"];
$item_query = $_GET["query"];
mijn probleem is: als ik het form method op GET zet, dan krijg ik $item_query, maar de andere 2 variabelen niet.
als ik het form method op POST zet, dan krijg ik de eerste 2 terug, maar $item_query niet.
hoe komt dit? doe ik iets fout met de POST / GET methodes, of moet ik het hele afvang principe anders aanpakken? wie helpt me? :) :P
alvast hartelijk bedankt,
Michael
latino
%Europe/Berlin %301 %2005, 08:13
das logisch he :)
Bij GET: SID.php?query=searchitem
zie jij inputitemname of inputitemtype erin staan? nee ik ook niet
Bij POST: SID.php?query=searchitem wordt niet meegegeven
ok dan kun je het beste volgens mij de velden nog een value meegeven
bijv:
<input type=hidden name=p value=24>
in je URL komt dan
p=24 , dus $_GET['p'] geeft 24
brossiekoppie
%Europe/Berlin %321 %2005, 08:43
Ik zie echt niet in waarom je niet $_POST zou gebruiken. Het is hier nochtans de beste oplossing.
Ik ben niet helemaal zeker maar ik dacht dat je het form door php liet echoën. Dus...
<html><body>
<?php
$mijnForm = '
<form action="'.$_SERVER['PHP_SELF'].'?q=searchitem" target="_self" method="post">
//hier je input tags uiteraard....
<input type="submit" name="komtiedan" />
</form>';
echo $mijnForm;
if ( isset ( $_POST['komtiedan'] ) ) {
$searched_item_name = $_POST['inputitemname'];
$searched_item_type = $_POST['inputitemtype'];
$item_query = $_GET['q'];
//zoekactie uitvoeren
}
?>
</body></html>
dioneo
%Europe/Berlin %490 %2005, 12:46
Je gebruikt idd post en get door elkaar heen. nooit doen, tenzij goed overwogen.
POST is absoluut de optie die je hier moet gebruiken. Verschillende redenen.
1-De gebruiker ziet de hidden values niet in de URL,
2-er zit een max aan de GET-versie, POST kan veel meer data transporteren
3-POST kun je iets moeilijker faken (je kunt gewoon een &iets=dit aan een GET-url toevoegen)
4- je kunt dmv
if($_SERVER['REQUEST_METHOD']=="POST"){
// parse data
header("Location: ".$_SERVER['PHP_SELF']);
} else {
// normale afhandeling
}
afvangen dat er een POST is gedaan, die afhandelen en vervolgens de pagina naar zichzelf laten doorsturen. Gevolg; NOOIT een dubbele POST, omdat via die header-methode alleen GET wordt meegegeven, geen POST, en de originele pagina waarheen gepost wordt nooit de browser bereikt dus niet in de history komt. Niets is zo irritant als een berichtje insturen, refreshen en vervolgens een dubbel bericht toegevoegd zien staan...
latino
%Europe/Berlin %530 %2005, 13:44
4- je kunt dmv
if($_SERVER['REQUEST_METHOD']=="POST"){
// parse data
header("Location: ".$_SERVER['PHP_SELF']);
} else {
// normale afhandeling
}
afvangen dat er een POST is gedaan, die afhandelen en vervolgens de pagina naar zichzelf laten doorsturen. Gevolg; NOOIT een dubbele POST, omdat via die header-methode alleen GET wordt meegegeven, geen POST, en de originele pagina waarheen gepost wordt nooit de browser bereikt dus niet in de history komt. Niets is zo irritant als een berichtje insturen, refreshen en vervolgens een dubbel bericht toegevoegd zien staan...
hmm zeer interresant..kun je hier meer over uitleggen..zo heb ik het nooit gedaan?
dioneo
%Europe/Berlin %558 %2005, 14:24
ik gebruik dit standaard. Ik had ooit problemen met een site die postvars gebruikt, en er werd nogal vaak F5 gebruikt. Dan herlaadt je de pagina inclusief postvars. Toen heb ik zitten broeden hoe de postvars uit een pagina te verwijderen nadat je ze hebt afgehandeld.
Toen kwam ik hierop, en dat werkt super. In stap 1 handel je je postvars af, herlaadt (maar dat merkt de browser niet; dat doet php intern) en toont de pagina zonder postvars. Die laatste kun je refreshen wat je wilt, een dubbele post komt niet meer voor.
De Kale
%Europe/Berlin %381 %2005, 10:09
volgens mij merkt de browser dat wel,
de header zegt dat de browser direct een andere pagina op moet vragen, dat dat heel erg snel gaat en dat jij dat niet merkt is iets anders.
Het is een erg creatieve en lgoede oplossing, maar niet echt transparant, het herladen van een pagina om iets op te lossen klinkt niet als een 'nette' oplossing.
Je zou ook tegen de database kunnen checken of diezelfde post al een keer eerder is voorgekomen aan de hand van de tekst, inputtijd, sessie data etcetera. dan is er geen page refresh nodig. Database input komt veel minder voor dan uitlezen (bijvootbeeld op dit forum) en de kost van die extra queries is dan te verwaarlozen tegen de extra veiligheid die je krijgt.
overigens vindt ik je argumenten 1 tm 3 niet erg sterk:
1. so what, als je de source bekijkt kun je het wel zienl, en mensen die erop letten weten ook wel hoe ze dat soort waarden kunnen lezen.
2. alleen bij oudere browsers kun je verwachten dat je daar tegenaan loopt, en als je zoveel data verstuurt zou je je af moeten vragen of je systeem wel goed is opgebouwd. (upload van file ipv hele grote lappen tekst bijvoorbeeld)
3. is allebei even makkelijk, en zo voor de hand liggend dat je je in ieder geval daar al tegen zou moeten beschermen via data validatie. Sterker nog, het kan heel fijn zijn als je get data aan kunt passen (bijvoorbeeld bij paginatie van items, zodat je meer items per pagina kunt zien, check onze portfolio maar eens op dpdk.nl)
vBulletin® v3.8.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.