DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Wat werkt er precies niet?quote:Op donderdag 9 januari 2014 13:29 schreef n8n het volgende:
Ik heb een class::functie() die een return geeft van een array of null. Nu werkt het alleen niet als ik if (empty(class::functie()) doe. Waarom is dat?
Zowel null als een lege array zijn empty. Kun je wat meer info geven?quote:
Ik heb een class::functie() die een return geeft van een array of null. Nu werkt het alleen niet als ik if (empty(class::functie()) doe. Waarom is dat?
Misschien overigens ook handiger om altijd een array te returnen i.p.v. ook de mogelijkheid tot null, zit je met een mixed type die waarschijnlijk niet nodig is in jouw situatie.
quote van php.net
Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.
oftewel, was je wil wordt niet ondersteund.
Dan zou ik dus Diabox zijn advies opvolgen, of false retouneren of als het echt nodig is is_null() te gebruiken ipv empty.
Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.
oftewel, was je wil wordt niet ondersteund.
Dan zou ik dus Diabox zijn advies opvolgen, of false retouneren of als het echt nodig is is_null() te gebruiken ipv empty.
-- ViPeRII --
Als je bij phpbb zelf een pagina hebt gemaakt waar je phpbb code hebt geinclude zodat je kan checken of de gebruiker is ingelogd etc.
kun je er voor zorgen dat die pagina niet meetelt in e wie is er online meuk.. want het gaat over een pagina die regelmatig met ajax word opgeroepen en als je dan de site open laat staan en niks doet blijf je online staan.
kun je er voor zorgen dat die pagina niet meetelt in e wie is er online meuk.. want het gaat over een pagina die regelmatig met ajax word opgeroepen en als je dan de site open laat staan en niks doet blijf je online staan.
quote:
helaasquote:Op donderdag 9 januari 2014 14:30 schreef ViPeRII het volgende:
quote van php.net
Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.
Ik doe een email query dmv een functie, als deze niet gevonden wordt return ik een null. ik maak nu een variabele van de functie die ik later gebruik. Was achteraf sowieso handiger omdat ik anders bij meerdere if statements de functie (en dus query) moet laten lopen en dat leek me onnodige overhead geven.quote:
[..]
Zowel null als een lege array zijn empty. Kun je wat meer info geven?
was eerst
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <?php // check email input if (empty($email)) { $error['email'] = 'empty'; } elseif (filter_var($email, FILTER_VALIDATE_EMAIL) == false) { $error['email'] = 'invalid'; } elseif (isset(user::check($email)) && (isset($register))) { $error['email'] = 'taken'; } elseif (empty(user::check($email)) && (isset($login))) { $error['email'] = 'absent'; } ?> |
is nu
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | <?php // check email input if (empty($email)) { $error['email'] = 'empty'; } elseif (filter_var($email, FILTER_VALIDATE_EMAIL) == false) { $error['email'] = 'invalid'; } else { // check if email input exists $user = user::check($email); if (isset($user['email']) && (isset($register))) { // registration: email already exists in database $error['email'] = 'taken'; } elseif (empty($user['email']) && (isset($login))) { // login: email address not in database $error['email'] = 'absent'; } } ?> |
de else op regel 11 is zodat de query alleen gedaan wordt als de andere statements niet van toepassing zijn
dit is de functie
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | <?php class user { static function check($email) { global $connect; $query = $connect->prepare("select id, email, userkey, password from user where email = :email"); $query->bindParam(':email', $email, PDO::PARAM_STR); $query->execute(); $user = $query->fetch(); if (empty($user)) { return null; } else { return $user; } } } ?> |
begrijp dat als ik hier meteen (zonder if) de $user variable return dat het ook werkt met empty($user).
[ Bericht 1% gewijzigd door n8n op 10-01-2014 14:42:48 ]
“Specialization is for insects”.—Robert Heinlein
waarom NULL? waarom niet gewoon false? if (($value == class::function()) != false) { // do dit } oid..
hoop dat ik het goed geschreven heb, want met deze syntax zit ik nog wel eens fout...
-edit-
dit gaat ook nergens over, waarom niet gewoon functies gebruiken die specifiek geschreven zijn om te kijken of er een resultaat is?
http://nl1.php.net/manual/en/pdostatement.rowcount.php
hoop dat ik het goed geschreven heb, want met deze syntax zit ik nog wel eens fout...
-edit-
dit gaat ook nergens over, waarom niet gewoon functies gebruiken die specifiek geschreven zijn om te kijken of er een resultaat is?
| 1 2 3 4 | $query = $connect->prepare("select id, email, userkey, password from user where email = :email"); $query->bindParam(':email', $email, PDO::PARAM_STR); $query->execute(); $user = $query->fetch(); |
http://nl1.php.net/manual/en/pdostatement.rowcount.php
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Je 'check' methode heeft een verantwoordelijkheid die die niet moeten hebben.
bool user::validEmailAdress(email)
user user::getUserbyEmailAdress(email)
of
bool user::validEmailAdress(email)
user user::getUserbyEmailAdress(email)
of
| 1 2 3 4 5 6 7 8 | user::getUserByEmailAdress(email) implementatie: checkEmailAdress(email) true: getUserbyEmailAdress(email) false: null |
Inderdaad wat bovenstaande heren zeggen. Ik verwacht sowieso bij een 'check' functie of het bestaat, en zodoende 'n boolean. Bij 'n get verwacht je data terug.
Daarnaast gewoon 'n lege array returnen bij geen resultaat, en 'n exception throwen wanneer iets fout gaat. Zo heb je geen mixed type nodig, en als er daadwerkelijk wat fout gaat krijg je gewoon 'n exception i.p.v. iets nietszeggends als false (al ga ik ook vaak voor 'n return false bij kleine dingetjes, maar bij wat grotere projecten, en zeker bij meerdere dingen die fout kunnen gaan, throw ik exceptions).
Daarnaast gewoon 'n lege array returnen bij geen resultaat, en 'n exception throwen wanneer iets fout gaat. Zo heb je geen mixed type nodig, en als er daadwerkelijk wat fout gaat krijg je gewoon 'n exception i.p.v. iets nietszeggends als false (al ga ik ook vaak voor 'n return false bij kleine dingetjes, maar bij wat grotere projecten, en zeker bij meerdere dingen die fout kunnen gaan, throw ik exceptions).
assert_valid_email en dan moet het ding dood gaan als het geen geldig adres is.
is het geldig: get_user_by(email => $email)
ik zou zoiets doen:
Dan kan je daarna gewoon een try { } catch (Exception $e) {} doen en dan ben je klaar. Doodgaan als het niet goed is, ik kan dat steeds meer waarderen.
is het geldig: get_user_by(email => $email)
ik zou zoiets doen:
| 1 2 3 4 5 6 7 8 9 | function assert_valid_email($meuk) { # $VALID_EMAIL_REGEXP is dan gewoon een constante, maar ik weet niet hoe dat eruit ziet in php if (preg_match($VALID_EMAIL_REGEXP, $meuk)) { return 1; } else { throw Exception("Invalid e-mail"); } } |
In theory there is no difference between theory and practice. In practice there is.
Het heeft inderdaad wel zo zijn voordelen, omdat je minder logic hoef te schrijven in het daadwerkelijke proces. Echter betwijfel ik of het gebruik van exceptions in elke validatie/conditionele case wel the way to go is. Ik zet ze zelf pas in bij de wat kritischere functies of externe aanroepen/services. Een vrij basale true/false case lijkt het me wel wat overkill.
Je kan een exceptie afvangen. Een invalide e-mailadres moet niet opgegeven zijn door je front-end en dient dus te klappen. De frontend kan ook wat met je Exception doen en klaar. Plus het test makkelijk.quote:
Het heeft inderdaad wel zo zijn voordelen, omdat je minder logic hoef te schrijven in het daadwerkelijke proces. Echter betwijfel ik of het gebruik van exceptions in elke validatie/conditionele case wel the way to go is. Ik zet ze zelf pas in bij de wat kritischere functies of externe aanroepen/services. Een vrij basale true/false case lijkt het me wel wat overkill.
Als fout: dan klappen, als goed, dan doorgaan.
Tuurlijk kan je ook een boolean value checken, maar als je get_user_by_email($email) doet en je mailadres is fout dan ga je geen null returnen omdat je mogelijk geen users vind en dan is een exception echt wel een betere oplossing. Daarom is het ook een assert_
Ik programmeer nu voor bedrijven (nouja, mijn ex-werkgever en mijn huidige werkgever) en daar checken we de params op het moment dat het binnenkomt. Als we dan een constante hebben ala VALID_EMAIL_SYNTAX en je propt er iets in wat geen valide e-mail is dan gaan we dood. Params::Check en familie. Dat is echt zo fijn programmeren.
Je krijgt dat dit soort code:
| 1 2 3 4 5 | sub get_user_by_email { my $args = check({email => {allow => VALID_EMAIL_REGEXP, required => 1},},{@_}); $db->resultset('User')->search({%$args})->single(); } |
Je mag dan maar 1 user hebben met dat mailadres want anders gaat DBIx::Class zeiken en je e-mailadres moet ook goed zijn anders gaat Params::Check zeiken en meer van zulks. Dat is zo fijn.
}
[ Bericht 6% gewijzigd door slacker_nl op 10-01-2014 22:36:27 ]
In theory there is no difference between theory and practice. In practice there is.
Eens.quote:
[..]
Je kan een exceptie afvangen. Een invalide e-mailadres moet niet opgegeven zijn door je front-end en dient dus te klappen. De frontend kan ook wat met je Exception doen en klaar. Plus het test makkelijk.
Als fout: dan klappen, als goed, dan doorgaan.
Tuurlijk kan je ook een boolean value checken, maar als je get_user_by_email($email) doet en je mailadres is fout dan ga je geen null returnen omdat je mogelijk geen users vind en dan is een exception echt wel een betere oplossing. Daarom is het ook een assert_
Bij het gebruik van asserts ben ik het volledig met je eens. Je beweert (assert) dan dat iets waar is. Zo niet: bam, exception!quote:
[..]
Je kan een exceptie afvangen. Een invalide e-mailadres moet niet opgegeven zijn door je front-end en dient dus te klappen. De frontend kan ook wat met je Exception doen en klaar. Plus het test makkelijk.
Als fout: dan klappen, als goed, dan doorgaan.
Tuurlijk kan je ook een boolean value checken, maar als je get_user_by_email($email) doet en je mailadres is fout dan ga je geen null returnen omdat je mogelijk geen users vind en dan is een exception echt wel een betere oplossing. Daarom is het ook een assert_
Maar stel: een admin zoekt naar een user op e-mailadres, dan heb je geen zekerheid dat het adres bestaat. In zo'n geval zou ik eerder een false/null/leeg iets verwachten ipv een exception. Het zit hem ook in de naam: een exception gaat om een uitzonderingsgeval of een onverwachte situatie. Zolang het proces binnen het verwachtingskader verloopt verwacht je geen exception. En in mijn voorbeeld kún je verwachten dat er geen user matcht op het ingegeven e-mailadres.
Uiteindelijk maakt het niet uit tot welk niveau je exceptions inzet, zolang je maar consequent bent want dat is veel waardevoller
In sommige gevallen is het wel degelijk een Exception als je naar iets zoekt en je vind er geen of meer dan een. Je database kan dan vervuild zijn en wat moet je dan geloven? In dit geval zouden er nul of een resultaten moeten zijn, je kan niet meerdere users met hetzelfde adres hebben. Vind je meer dan twee users dan moet je m.i. een exceptie rond gaan gooien.quote:
Bij het gebruik van asserts ben ik het volledig met je eens. Je beweert (assert) dan dat iets waar is. Zo niet: bam, exception!
Maar stel: een admin zoekt naar een user op e-mailadres, dan heb je geen zekerheid dat het adres bestaat. In zo'n geval zou ik eerder een false/null/leeg iets verwachten ipv een exception. Het zit hem ook in de naam: een exception gaat om een uitzonderingsgeval of een onverwachte situatie. Zolang het proces binnen het verwachtingskader verloopt verwacht je geen exception. En in mijn voorbeeld kún je verwachten dat er geen user matcht op het ingegeven e-mailadres.
Uiteindelijk maakt het niet uit tot welk niveau je exceptions inzet, zolang je maar consequent bent want dat is veel waardevoller
Overigens vind ik in dit geval dat get_user_by_email er ongeveer zo gaat uitzien:
| 1 2 3 4 5 | getuser_by_email { assert_valid_email($email); my @res = $db->search('User', email => $email); throw("Multiple users found where one or less expected") if @res > 1; } |
syntax is perl, maar dat boeit even niet
Als je zoekt op een userid bijvoorbeeld, dan moet je code wel gaan lopen miepen als die user niet bestaat, die ID heb je ergens vandaan. Het gaat inderdaad om de context, maar bij rariteiten verkies is voor excepties en doodgaan. Als de caller dit kan afhandelen kan ie de exceptie afvangen en verder gaan.
In theory there is no difference between theory and practice. In practice there is.
Het is een form met 2 submits, 1 registeer en 1 login (al kan het ook apart). De email input check doet eerst een check of er überhaupt een waarde is, dan of de email geldig is en als dat klopt afhankelijk van de submit een query voor het ingevoerde adres. Bij registreer krijgt het een ok als het email adres niet bestaat, bij login als het wel bestaat. Als een statement niet werkt maak ik een error array aan. Het hele form werkt pas als er na alle checks geen errors zijn.
Is dit een beetje okay? Zie dat er een hele discussie ontstaat
. Heb nu bij de user::check($email) gedaan dat er altijd een array in de return staat. Zal de functie nog hernoemen naar user::get().
Is met pdo filter_var($email, FILTER_VALIDATE_EMAIL) voldoende sanatising. Begreep dat pdo al goed beveiligd was als je params gebruikt
Is dit een beetje okay? Zie dat er een hele discussie ontstaat
. Heb nu bij de user::check($email) gedaan dat er altijd een array in de return staat. Zal de functie nog hernoemen naar user::get(). Is met pdo filter_var($email, FILTER_VALIDATE_EMAIL) voldoende sanatising. Begreep dat pdo al goed beveiligd was als je params gebruikt
“Specialization is for insects”.—Robert Heinlein
Ik gooi altijd dat Exceptions in situaties die eigenlijk niet mogen voorkomen.
Dat er een gebruiker niet kan worden gevonden op een e-mail adres is prima. Dat kan voorkomen, bijvoorbeeld bij een check als de gebruiker al eens in aangemeld. De hoeveelheid e-mail adressen mogen niet meerdere keren voorkomen omdat dit als PK / ID wordt gezien. In het geval dat er 2 gebruikers worden geretourneerd door de methode getUserByEmail() is er iets mis met 1) de DB (itegriteit) en 2) de Code. In dat geval zal ik echt, boem een Exception gooien. Hence de naam 'Exception'.
Dat er een gebruiker niet kan worden gevonden op een e-mail adres is prima. Dat kan voorkomen, bijvoorbeeld bij een check als de gebruiker al eens in aangemeld. De hoeveelheid e-mail adressen mogen niet meerdere keren voorkomen omdat dit als PK / ID wordt gezien. In het geval dat er 2 gebruikers worden geretourneerd door de methode getUserByEmail() is er iets mis met 1) de DB (itegriteit) en 2) de Code. In dat geval zal ik echt, boem een Exception gooien. Hence de naam 'Exception'.
omdat ik de informatie wil gebruiken om het wachtwoord te validerenquote:
waarom NULL? waarom niet gewoon false? if (($value == class::function()) != false) { // do dit } oid..
hoop dat ik het goed geschreven heb, want met deze syntax zit ik nog wel eens fout...
-edit-
dit gaat ook nergens over, waarom niet gewoon functies gebruiken die specifiek geschreven zijn om te kijken of er een resultaat is?
[ code verwijderd ]
http://nl1.php.net/manual/en/pdostatement.rowcount.php
“Specialization is for insects”.—Robert Heinlein
in principe kan het toch niet voorkomen, sowieso is elk email adres in de tabel uniek.quote:
Ik gooi altijd dat Exceptions in situaties die eigenlijk niet mogen voorkomen.
Dat er een gebruiker niet kan worden gevonden op een e-mail adres is prima. Dat kan voorkomen, bijvoorbeeld bij een check als de gebruiker al eens in aangemeld. De hoeveelheid e-mail adressen mogen niet meerdere keren voorkomen omdat dit als PK / ID wordt gezien. In het geval dat er 2 gebruikers worden geretourneerd door de methode getUserByEmail() is er iets mis met 1) de DB (itegriteit) en 2) de Code. In dat geval zal ik echt, boem een Exception gooien. Hence de naam 'Exception'.
“Specialization is for insects”.—Robert Heinlein
Assumption is the mother of all fuckups. Juist dat 'in principe' is waarom je een exception gooit.quote:
[..]
in principe kan het toch niet voorkomen, sowieso is elk email adres in de tabel uniek.
duidelijk, als ik eigenwijs klink is dat omdat ik het nog onduidelijk heb. Schrijf je die exception dan in de functie if als else statement na de if?quote:
[..]
Assumption is the mother of all fuckups. Juist dat 'in principe' is waarom je een exception gooit.
Nog iets anders, ik schrijf nu elke class in een aparte php file, doe ik zodat ik het overzicht hou en het leek me handig omdat ik bepaalde files dan alleen hoef te includen waar nodig. Vroeg me af of het zinnig is en niet te veel overhead gaf als er veel bestanden ingelezen moeten worden.
“Specialization is for insects”.—Robert Heinlein
Iedere class in een file is vrij gebruikelijk, zelf includen niet. Gebruik je een framework? Meeste frameworks hebben dat geautoriseerd.
nee probeer eerst standaard php te leren. Over een week stage, daar werken ze met lavarel oid. Vandaag proberen homebrew aan te praat te krijgen ipv mamp en heb volgens mij m'n apache config file verneuktquote:Op zondag 12 januari 2014 16:41 schreef KomtTijd... het volgende:
Iedere class in een file is vrij gebruikelijk, zelf includen niet. Gebruik je een framework? Meeste frameworks hebben dat geautoriseerd.
“Specialization is for insects”.—Robert Heinlein
Vond dit wel een aardige verzameling, misschien heeft iemand er nog iets aan:
Artful Common MySQL Queries.
Artful Common MySQL Queries.
When the student is ready, the teacher will appear.
When the student is truly ready, the teacher will disappear.
When the student is truly ready, the teacher will disappear.
