[PHP] Case of If Else constructie?

[ViNyL]

Ik heb in 1 php file een aantal stappen die doorlopen moeten worden.


Je selecteert eerst een afdeling, vervolgens klik je op submit. Als er op submit geklikt is moet je naar het volgende form gaan.


Nou heb ik begrepen dat je dit met een if / else constructie kan doen. Als er geen submit waarde is kom je op het eerste form uit. Klik je daar op submit dan kom je op het tweede form uit. En kies je daar weer een optie en klik je op submit dan kom je op het derde form uit.


Nou heb ik een beetje lopen proberen maar ik kom niet echt ver. Dit is wat ik tot nu toe geprobeerd heb:

PHP:

if ($submit == 'submit1') 
{ 
// Stage 1
}
elseif ($submit == 'submit2') { 
// Stage 2
}else{
// Default Stage
};

Ik geef als "value" in de sybmit button tag dus "submit1" en "submit2" mee, maar het werkt nog niet helemaal naar behoren. Ik blijf op form 1 hangen (de default stage).


Hoe werkt zoiets? Ik heb ook gelezen begrepen dat je iets met een "case" kan in PHP?

[Spixo]

Ik neem aan dat je gewoon $_POST['submit'] ipv $submit moet gebruiken

[ Voor 32% gewijzigd door Spixo op 30-08-2004 20:05 ]

[ViNyL]

Lol dan werkt het idd wel..omg!


Bedankt. Dat het zo simpel was dat had ik niet echt gedacht. Klein foutje in mijn code dus.

[Spixo]

ViNyL schreef op 30 augustus 2004 @ 20:07:
Lol dan werkt het idd wel..omg!


Bedankt. Dat het zo simpel was dat had ik niet echt gedacht. Klein foutje in mijn code dus.

Kijk ook eens naar de onderstaande pagina en dan vooral naar $_POST en $_GET:


http://nl.php.net/globals

[4Real]

PHP:

switch($_POST['submit'])
{
    case 'submit1':
        //
        // prut hier
        //
        break;

    case 'submit2':
        //
        // prut hier
        //
        break;

    case default:
        //
        // geen match dus else zeg maar
        //
        break;
}

misschien wat netter en sneller.

[Jimbolino]

of anders zet je bovenaan:

code:

extract ($_POST);

dan kun je gewoon $submit gebruiken

[Erkens]

Jimbolino schreef op 30 augustus 2004 @ 21:55:
of anders zet je bovenaan:

code:

extract ($_POST);

dan kun je gewoon $submit gebruiken

en weg is het nut en de veiligheid van de superglobals....

[Verwijderd]

4Real schreef op 30 augustus 2004 @ 20:10:

PHP:

switch($_POST['submit'])
{
    case 'submit1':
        //
        // prut hier
        //
        break;

    case 'submit2':
        //
        // prut hier
        //
        break;

    case default:
        //
        // geen match dus else zeg maar
        //
        break;
}

misschien wat netter en sneller.

Netter wel, maar kwa snelheid zal het niet zo veel uitmaken met een stuk of wat cases.

[Verwijderd]

Een case/switch is lelijk en moet waar mogelijk vermeden worden.


Ik weet je precieze toepassing niet, maar anders zou ik een dispatch table gebruiken of een object-geörienteerde oplossing nastreven.

[Erkens]

Verwijderd schreef op 30 augustus 2004 @ 22:37:
Netter wel, maar kwa snelheid zal het niet zo veel uitmaken met een stuk of wat cases.

En netheid vergroot de onderhoudbaarheid van de applicatie waarmee de ontwikkeltijd korter wordt, dus toch veel snelheidswinst
(servers zijn vaak snel genoeg dat die paar ms. niks uitmaken)

[NMe]

Erkens schreef op 30 augustus 2004 @ 22:20:
en weg is het nut en de veiligheid van de superglobals....

Niet als je alleen $_POST extract.

Verwijderd schreef op 30 augustus 2004 @ 22:40:
Een case/switch is lelijk en moet waar mogelijk vermeden worden.

Joh, onderbouw dat voor de lol eens... Er is niets mis met een switch, en ook object georiënteerd zal het niet veel sneller gaan, hooguit iets netter qua code, maar een switch is van zichzelf al vrij net en lesbaar...

[crisp]

[puriteinse zeurmodus]
geef een form-element nooit een name="submit":


1) je overschrijft de javascript submit() method
2) een formulier gesubmit met een enter stuurt niet de waarde van de submit button mee
3) een formulier gesubmit dmv javascript stuurt ook niet de waarde van de submit button mee, maar zover kom je niet eens vanwege 1)
[/]

[ Voor 24% gewijzigd door crisp op 31-08-2004 01:40 ]

[Grijze Vos]

Verwijderd schreef op 30 augustus 2004 @ 22:40:
Een case/switch is lelijk en moet waar mogelijk vermeden worden.

Grappig, mij wordt toch altijd nog geleerd dat je if/elseif's moet vermijden, en case statements moet gebruiken.

[Rac-On]

Verwijderd schreef op 30 augustus 2004 @ 22:40:
Een case/switch is lelijk en moet waar mogelijk vermeden worden.


Ik weet je precieze toepassing niet, maar anders zou ik een dispatch table gebruiken of een object-geörienteerde oplossing nastreven.

Ik hoop dat je hier een onderbouwing voor hebt.. ALs je netjes tab gebruikt, dan is een case veel netter en leesbaarder dan een case.... Je hoeft namelijk niet de hele tijd het $variable== neer te zetten, maar alleen je waarde...


Daarnaast is de case ook veel sneller dan de elseif, omdat je niet alle voorwaardes door hoeft om de laatste else te matchen..


Een dispatch table of OO model is een beetje overdreven om te kijken in deze situatie, denk je ook niet? TS wil alleen weten wat de waarde van zijn variable is...

[Erkens]

NMe84 schreef op 31 augustus 2004 @ 01:35:
[...]


Niet als je alleen $_POST extract.

Ben ik het niet helemaal mee eens.


Want als ik dergelijke code lees, dan is het vrij lastig te bepalen waar die variabele vandaan komt, wat dus kans op veiligheidrisico's vergroot.
Daarnaast, mensen die deze functie gebruiken doen dat doorgaands ook direct voor $_GET, $_SESSION en $_COOKIES, dat kan je niet ontkennen, immers "dat is makkelijk" maar geloof me, die paar extra tekens die je in moet typen zijn het wel waard. Zowel voor de leesbaarheid en daarmee de veiligheid.

Joh, onderbouw dat voor de lol eens... Er is niets mis met een switch, en ook object georiënteerd zal het niet veel sneller gaan, hooguit iets netter qua code, maar een switch is van zichzelf al vrij net en lesbaar...

idd, een switch vind ik leesbaarder dan een tigduizend geneste if-statements. Ik denk dat het "probleem" zit bij het niet snappen van de "break"

[paulh]

Erkens schreef op 31 augustus 2004 @ 08:13:
idd, een switch vind ik leesbaarder dan een tigduizend geneste if-statements. Ik denk dat het "probleem" zit bij het niet snappen van de "break"

Idd .. ik denk dat een hoop mensen niet van de fallthrough regel gehoord hebben.

[Creepy]

paulh schreef op 31 augustus 2004 @ 08:17:
[...]
Idd .. ik denk dat een hoop mensen niet van de fallthrough regel gehoord hebben.

Maar om daarmee een case nu gelijk lelijk te vinden en helemaal niet te gebruiken is ook weer wat overdreven........ In o.a. Pascal heeft een case geen falltrough. Het nadeel aan o.a. Pascal, maar ook C en C++ is dat een switch/case geen strings ondersteunt en je alsnog met een flinke if aan de slag moet. Then again, ik zou dan constanten gebruiken om alsnog van een case gebruik te kunnen maken.

[ Voor 29% gewijzigd door Creepy op 31-08-2004 08:21 ]

[Erkens]

Creepy schreef op 31 augustus 2004 @ 08:20:
[...]


Maar om daarmee een case nu gelijk lelijk te vinden en helemaal niet te gebruiken is ook weer wat overdreven........

Maar omdat sommige mensen die switch-statements niet snappen gebruiken ze het niet en vinden ze het lelijk, ik snap dat wel hoor

In o.a. Pascal heeft een case geen falltrough. Het nadeel aan o.a. Pascal, maar ook C en C++ is dat een switch/case geen strings ondersteunt en je alsnog met een flinke if aan de slag moet. Then again, ik zou dan constanten gebruiken om alsnog van een case gebruik te kunnen maken.

constanten ipv strings?
Ik zou eerder een hash gebruiken

[paulh]

Creepy schreef op 31 augustus 2004 @ 08:20:
Then again, ik zou dan constanten gebruiken om alsnog van een case gebruik te kunnen maken.

Tsja dat gaat een beetje moeilijk als je strings wilt vergelijken .

[Creepy]

paulh schreef op 31 augustus 2004 @ 08:36:
[...]
Tsja dat gaat een beetje moeilijk als je strings wilt vergelijken .

In de case gebruik je vooraf gedefinieerde strings. Mocht je geen form variabelen / knoppen (zoals een submit knop) afvangen dan hoef je hier echt geen strings voor te gebruiken. Zelfs in PHP kan je de value van een button een integer waarde meegeven. Door het typejuggling systeem van PHP is het dan nog ineens een echte integer waarde ook en daardoor weer een prima kandidaat voor een constante
Maar aangezien PHP en tegenwoordig ook C# (en java ook??) switch/case statements ondersteunen met strings....

[paulh]

Ja zo kan ik nog wel een stel situaties bedenken waarbij je strings kan voorkomen maar daar ging het me niet om.

[NMe]

Erkens schreef op 31 augustus 2004 @ 08:13:
Ben ik het niet helemaal mee eens.


Want als ik dergelijke code lees, dan is het vrij lastig te bepalen waar die variabele vandaan komt, wat dus kans op veiligheidrisico's vergroot.
Daarnaast, mensen die deze functie gebruiken doen dat doorgaands ook direct voor $_GET, $_SESSION en $_COOKIES, dat kan je niet ontkennen, immers "dat is makkelijk" maar geloof me, die paar extra tekens die je in moet typen zijn het wel waard. Zowel voor de leesbaarheid en daarmee de veiligheid.

Ik weet wat je bedoelt, en ik werk zelf ook nooit met extract(). De variabele noemen bij zijn echte naam en weten waar hij vanaf komt is nou eenmaal een stuk veiliger, en vind het zelf overzichtelijker. Maar als je alleen $_POST extract en de andere superglobals met rust laat, dan is het niet onveilig, omdat je dan wel degelijk weet waar de variabelen vanaf komen. Dat het niet overzichtelijk is omdat je de variabele niet echt kan volgen ben ik met je eens, maar onveilig is het niet.
_{In tegenstelling tot het extracten van $_REQUEST.}

[Erkens]

NMe84 schreef op 31 augustus 2004 @ 13:30:
De variabele noemen bij zijn echte naam en weten waar hij vanaf komt is nou eenmaal een stuk veiliger, en vind het zelf overzichtelijker. Maar als je alleen $_POST extract en de andere superglobals met rust laat, dan is het niet onveilig, omdat je dan wel degelijk weet waar de variabelen vanaf komen. Dat het niet overzichtelijk is omdat je de variabele niet echt kan volgen ben ik met je eens, maar onveilig is het niet.

Dus als jij een stuk code leest en plotseling ergens een variabele $naam tegenkomt, terwijl die nergens gedefinieerd is, dan weet je direct dat dit userinput is? Ik ben van mening dat zodra je dergelijke variabele gebruikt de kans enorm groot is dat het onveilige situaties kan creeeren.
Per definitie is het uiteraard niet onveilig, maar over het algemeen wordt het wel onveilig gebruikt.

Maargoed, genoeg offtopic

[Olaf van der Spek]

NMe84 schreef op 31 augustus 2004 @ 13:30:
Ik weet wat je bedoelt, en ik werk zelf ook nooit met extract(). De variabele noemen bij zijn echte naam en weten waar hij vanaf komt is nou eenmaal een stuk veiliger, en vind het zelf overzichtelijker. Maar als je alleen $_POST extract en de andere superglobals met rust laat, dan is het niet onveilig, omdat je dan wel degelijk weet waar de variabelen vanaf komen. Dat het niet overzichtelijk is omdat je de variabele niet echt kan volgen ben ik met je eens, maar onveilig is het niet.
_{In tegenstelling tot het extracten van $_REQUEST.}

Hoezo is extract($_POST) veilig maar extract($_GET) niet?

[Erkens]

OlafvdSpek schreef op 31 augustus 2004 @ 18:28:
[...]

Hoezo is extract($_POST) veilig maar extract($_GET) niet?

niks, maar hij bedoelt dat je ze niet beide moet gebruiken

[Olaf van der Spek]

Erkens schreef op 31 augustus 2004 @ 18:30:
niks, maar hij bedoelt dat je ze niet beide moet gebruiken

Dat haal ik toch echt niet uit de volgende zin:

Maar als je alleen $_POST extract en de andere superglobals met rust laat, dan is het niet onveilig, omdat je dan wel degelijk weet waar de variabelen vanaf komen.

[Erkens]

Je quote precies wat hij bedoelt en wat ik zei

zodra je alleen $_POST extract en de andere superglobals met rust laat......

[Olaf van der Spek]

Dan weet je toch nog steeds niet of $a nou $_post['a'] is of ergens anders vandaan komt?

[djluc]

OlafvdSpek schreef op 31 augustus 2004 @ 19:17:
Dan weet je toch nog steeds niet of $a nou $_post['a'] is of ergens anders vandaan komt?

Als je het heel simpel bekijkt heb je gelijk: het kan een lokale variable zijn of een POST var.

[Erkens]

OlafvdSpek schreef op 31 augustus 2004 @ 19:17:
Dan weet je toch nog steeds niet of $a nou $_post['a'] is of ergens anders vandaan komt?

Dat is nu juist het hele punt

Zodra je met extract werkt weet je niet meer waar ze vandaan komen, dat is dus verwarrend, en kan leiden tot onveilige situaties

[Olaf van der Spek]

Maar NMe84 zegt toch juist dat het niet onveilig (dus veilig) is?

[Erkens]

OlafvdSpek schreef op 31 augustus 2004 @ 19:35:
Maar NMe84 zegt toch juist dat het niet onveilig (dus veilig) is?

mja, het hoeft niet onveilig te zijn, immers je kan super veilige applicaties ermee schrijven, alleen 999 van de 1000x gebeurd dat niet