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.
Als je vragen hebt over PHP/MySQL, dan zit je hier goed met een vaste kliek guru's en een groot aantal regelmatige bezoekers. Beperk je vragen niet tot "hij doet het niet" of "hij geeft een fout" - onze glazen bol is kapot en we willen graag van je weten wát er niet lukt en wélke foutmelding je precies krijgt
Zie ook:
• PHP Dataverwerking
• Officiële PHP website
• PHP Documentatie
• MySQL Reference Manual
• Yet Another PHP Faq
• PHP Cheat Sheet
• PHP5 Power Programming - boek met uitleg over OOP, Pear, XML, etc
Tutorials:
• W3Schools PHP
• W3Schools SQL
Succes heren met het volgende deeltje!
In theory there is no difference between theory and practice. In practice there is.
Om er maar eens eentje in te gooien: waarom zie ik deze topics zoveel gebruik van mysql_* of mysqli_* en zo weinig van PDO?
Tegenwoordig moet je Dr. Ir. zijn om een beetje correct Nederlands te kunnen neerpleuren.
Abusing semicolons since 1987.
Abusing semicolons since 1987.
Vind het prettiger in gebruik dan mysqli in OOP.quote:Op maandag 16 december 2013 16:39 schreef rekenwonder het volgende:
Om er maar eens eentje in te gooien: waarom zie ik deze topics zoveel gebruik van mysql_* of mysqli_* en zo weinig van PDO?
Ben net begonnen met OOP (en PHP eigenlijk ook lol).
[ Bericht 1% gewijzigd door #ANONIEM op 16-12-2013 17:13:42 ]
Voor een beginner lijkt het me op zich wel goed om te beginnen met mysql_( i ) en daarna PDO.quote:
Om er maar eens eentje in te gooien: waarom zie ik deze topics zoveel gebruik van mysql_* of mysqli_* en zo weinig van PDO?
Terrorism is the poor mans war, war is the rich mans terrorism.
Mij niet. Alleen maar nadelen.quote:Op maandag 16 december 2013 17:24 schreef Baghdaddy het volgende:
[..]
Voor een beginner lijkt het me op zich wel goed om te beginnen met mysql_(i) en daarna PDO.
Hoezo?quote:
Voor een beginner lijkt het me op zich wel goed om te beginnen met mysql_( i ) en daarna PDO.
Nee ik trek mijn bewering terug. In mijn geval vond ik het handig om kennis te maken met PHP en MySQL m.b.v. mysql_i omdat het mij wat simpeler leek om te begrijpen. Als ik terugkijk had ik PDO liever eerder ontdektquote:
.
Terrorism is the poor mans war, war is the rich mans terrorism.
haal die haakjes eens weg.quote:
[..]
Voor een beginner lijkt het me op zich wel goed om te beginnen met mysql_( i ) en daarna PDO.
Onzinreden. Gelijk met PDO beginnen. Leer je het in een keer goed, kan je ook makkelijk meenemen naar andere talen waar ze soortgelijke dingen hebben zoal DBI in Perl.quote:
[..]
Voor een beginner lijkt het me op zich wel goed om te beginnen met mysql_( i ) en daarna PDO.
In theory there is no difference between theory and practice. In practice there is.
De mysql_* functies moet je sowieso niet meer gebruiken (tenzij je een fix gaat doen in bestaande code die van die functies gebruik maakt). Die zijn officieel deprecated en gaan er in de toekomst helemaal uit.quote:
Om er maar eens eentje in te gooien: waarom zie ik deze topics zoveel gebruik van mysql_* of mysqli_* en zo weinig van PDO?
Er zit ook helemaal geen voordeel aan, en mysqli is niet ingewikkelder ofzo.quote:
[..]
De mysql_* functies moet je sowieso niet meer gebruiken (tenzij je een fix gaat doen in bestaande code die van die functies gebruik maakt). Die zijn officieel deprecated en gaan er in de toekomst helemaal uit.
True, maar ik had het er specifiek over dat je niet mysql_ moet gebruiken. mysqli_ kan prima, maar ik zou PDO aanraden.quote:
[..]
Er zit ook helemaal geen voordeel aan, en mysqli is niet ingewikkelder ofzo.
Wel als je geen OOP ervaring hebt.quote:
[..]
Er zit ook helemaal geen voordeel aan, en mysqli is niet ingewikkelder ofzo.
"You know what Hell really is? It's not lakes of burning oil or chains of ice. It's being removed from God's sight."
Ook dan is PDO makkelijker. De syntax is prima in procedurele code te verwerken zonder enige kennis van OOP.quote:Op dinsdag 17 december 2013 10:16 schreef Devolution het volgende:
[..]
Wel als je geen OOP ervaring hebt.
Klopt.quote:Op dinsdag 17 december 2013 10:49 schreef KomtTijd... het volgende:
[..]
Ook dan is PDO makkelijker. De syntax is prima in procedurele code te verwerken zonder enige kennis van OOP.
Heck, misschien is het zelfs een goede eerste stap voor mensen die procedureel programmeren om vast wat inzicht te krijgen in OOP.
Heeft voor mij ook goed gewerkt, dat ik in het verleden wat gekloot heb met DateTime-objecten maakt dat ik nu het OOP programmeren toch wat makkelijker oppik.
Heeft voor mij ook goed gewerkt, dat ik in het verleden wat gekloot heb met DateTime-objecten maakt dat ik nu het OOP programmeren toch wat makkelijker oppik.
Ik heb een probleempje!
Het volgende heb ik op dit moment:
Het bovenstaande moet naar http://www.xxx.nl/cms/req(...)h&searchtext=artiest gaan, maar dat doet ie niet
Hij maakt er nu dit van: http://www.xxx.nl/cms/requests/request.php?searchtext=Misss
Dus het mist ?func=Search&
Iemand hier die kan helpen?
Het volgende heb ik op dit moment:
| 1 2 3 4 | <form method="request" action="http://www.xxx.nl/cms/requests/request.php?func=Search&" id="searchform"> <h1>Artiest</h1> <input type="text" name="searchtext" /> </form> |
Het bovenstaande moet naar http://www.xxx.nl/cms/req(...)h&searchtext=artiest gaan, maar dat doet ie niet
Hij maakt er nu dit van: http://www.xxx.nl/cms/requests/request.php?searchtext=Misss
Dus het mist ?func=Search&
Iemand hier die kan helpen?
Volgens mij bestaat er geen request methode genaamt 'request'. En je zult idd een hidden input moeten gebruiken om extra variablen mee te geven aan een get request.
Waarom werk je via get variabelen in je URL om een zoek functie uit te voeren? Je kunt toch sowieso gewoon in je cms/request/search.php?query=artiestnaam doen en aan de achterkant uitzoeken of er op een artiest moet worden gezocht of een combinatie van variabelen?quote:
Ik heb een probleempje!
Het volgende heb ik op dit moment:
[ code verwijderd ]
Het bovenstaande moet naar http://www.xxx.nl/cms/req(...)h&searchtext=artiest gaan, maar dat doet ie niet
Hij maakt er nu dit van: http://www.xxx.nl/cms/requests/request.php?searchtext=Misss
Dus het mist ?func=Search&
Iemand hier die kan helpen?
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Gehele map /request/ wordt aangeleverd door de software maker van onze playout systeem. Dus wil er niet teveel in veranderen binnen die code vanwege updates etc. Voor nu de makkelijkste optie.quote:
[..]
Waarom werk je via get variabelen in je URL om een zoek functie uit te voeren? Je kunt toch sowieso gewoon in je cms/request/search.php?query=artiestnaam doen en aan de achterkant uitzoeken of er op een artiest moet worden gezocht of een combinatie van variabelen?
Daarom houdt je altijd een UPDATE log bijquote:
[..]
Gehele map /request/ wordt aangeleverd door de software maker van onze playout systeem. Dus wil er niet teveel in veranderen binnen die code vanwege updates etc. Voor nu de makkelijkste optie.
de updates die je zelf maakt kunnen in het geval van een template update zo weer aangepast worden.
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Protip: patch-files.quote:
[..]
Daarom houdt je altijd een UPDATE log bij
Tegenwoordig moet je Dr. Ir. zijn om een beetje correct Nederlands te kunnen neerpleuren.
Abusing semicolons since 1987.
Abusing semicolons since 1987.
Juist. Url? verwijzing?quote:
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
http://lmgtfy.com/?q=how+to+create+a+patchquote:
man diff, man patch
Overigens zou ik de wijzigingen doorvoeren in de code en die opsturen naar de leverancier in een patch file zodat zij de patch kunnen toevoegen aan hun source tree en daarna heb je minder problemen tijdens een upgrade. Zo werktte ik altijd met interne leveranciers (onze developers), wij de engineers wilden hun code soms aanpassen vanwege bugs of issues en ze kregen dan de patch terug zodat een volgende release de wijziging bevatte en niemand meer de code hoefde aan te passen.
In theory there is no difference between theory and practice. In practice there is.
Hallo,
Ik wil urls decoden met rawurldecode();
probleem is als ik em echo werkt het prima, maar als ik em in een mysql tabel zet werkt het niet, als ik em bij phpbb in zo'n php bestand zet en dan in html bestand oproep met {BLABLA} werkt het niet, om de een of andere reden blijft ie dan gewoon geencode..
Iemand?
Ik wil urls decoden met rawurldecode();
probleem is als ik em echo werkt het prima, maar als ik em in een mysql tabel zet werkt het niet, als ik em bij phpbb in zo'n php bestand zet en dan in html bestand oproep met {BLABLA} werkt het niet, om de een of andere reden blijft ie dan gewoon geencode..
Iemand?
Ik volg het niet helemaal. De functie rawurldecode() geeft een string terug. Wat wil je er mee kunnen doen? Want ik snap niet wat MySQL en/of html hiermee te maken heeft 
[ Bericht 0% gewijzigd door zoem op 06-01-2014 18:03:13 ]
[ Bericht 0% gewijzigd door zoem op 06-01-2014 18:03:13 ]
Ik doe:quote:
Ik volg het niet helemaal. De functie rawurlencode() geeft een string terug. Wat wil je er mee kunnen doen? Want ik snap niet wat MySQL en/of html hiermee te maken heeft
$string = rawurldecode($string);
echo $string;
Werkt krijg de string gedecode terug..
mysql_query("UPDATE table SET veld='$string'");
In mysql staat de string nog steeds geencode..
Ik geef in phpbb dit mee aan het template bestand:
$template->assign_vars(array(
'STRING' => $string,
));
in template bestand zet ik em er zo in {STRING}
Het resultaat is een geencode string.. dus rawurldecode heeft weer niks gedaan. terwijl dat met echo wel het geval is.
Ja ik begrijp er ook niks van anders had ik het hier niet gevraagd..
EDIT: ah.. als je em echoed word ie uberhaupt gedecode.. dus waarschijnlijk doet rawurldecode uberhaupt niks.. kzal wel een andere functie nodig hebben ofzo..
[ Bericht 3% gewijzigd door Skunk-m op 06-01-2014 18:05:58 ]
PHP Echo doet niets decoden hoor. Wellicht doet je browser dat als je de output in een internetbrowser bekijkt.
Verder snap ik het ook niet, lijkt me dat je ergens een typfout of volorde fout maakt ofzo. Debuggen dus.
Verder snap ik het ook niet, lijkt me dat je ergens een typfout of volorde fout maakt ofzo. Debuggen dus.
Geeft niet, alleen je verhaal was ietwat wazigquote:
Ja ik begrijp er ook niks van anders had ik het hier niet gevraagd..
Ah kijk, dan heb je iig een aanknopingspunt. Je kunt beter var_dump() gebruiken ipv echo, omdat dan de weergave (beter) overeenkomt met de inhoud van je variabele en kijk bij voorkeur naar de bron van je pagina ipv de pagina zelf.quote:EDIT: ah.. als je em echoed word ie uberhaupt gedecode.. dus waarschijnlijk doet rawurldecode uberhaupt niks.. kzal wel een andere functie nodig hebben ofzo..
Ja ik had em al tussen script tags gezet en daarna in de bron gekeken..quote:Ah kijk, dan heb je iig een aanknopingspunt. Je kunt beter var_dump() gebruiken ipv echo, omdat dan de weergave (beter) overeenkomt met de inhoud van je variabele en kijk bij voorkeur naar de bron van je pagina ipv de pagina zelf.
schijnbaar was ie gehtmlentitied nu heb k html_entity_decode() gebruikt en dat werkt.
iig bedankt
HTML <script> tags bedoel je? Dat is een manier om javascript code te embedden, heb je ook niets aan. <pre> tags kunnen soms nuttig zijn, maar om je rauwe output te zien moet je altijd gewoon de paginabron bekijken inderdaad.quote:
[..]
Ja ik had em al tussen script tags gezet en daarna in de bron gekeken..
schijnbaar was ie gehtmlentitied nu heb k html_entity_decode() gebruikt en dat werkt.
iig bedankt
iig bug gevonden dus
Ik moet het toch even vragen: Die mysql_ functie was alleen voor het voorbeeld toch hoop ik?
oja in de bron kijken had misschien ook gekunt, maar ik keek bij element bekijken gebeuren in chrome zeg maar en daar was het ook gewoon gedecode, maar ik moest bij phpbb in een javascript code hebben en daar stond ie wel verkeerd, dus had ik bij mn testbestandje ook maar even script tags eromheen gezet.. maar het is iig opgelost ja.quote:HTML <script> tags bedoel je? Dat is een manier om javascript code te embedden, heb je ook niets aan. <pre> tags kunnen soms nuttig zijn, maar om je rauwe output te zien moet je altijd gewoon de paginabron bekijken inderdaad.
iig bug gevonden dus
Ik moet het toch even vragen: Die mysql_ functie was alleen voor het voorbeeld toch hoop ik?
Bheheh.
http://www.php.net/manual/en/function.delete.phpquote:delete
delete — See unlink() or unset()
Description ¶
This is a dummy manual entry to satisfy those people who are looking for unlink() or unset() in the wrong place.
quote:Op donderdag 9 januari 2014 01:15 schreef KomtTijd... het volgende:
Bheheh.
[..]
http://www.php.net/manual/en/function.delete.php
Volgens mij staat dat aardig beschreven, omdat de unlink functie ook in C gebruikt wordt... oh en delete oftewel del is een 'dos' commandoquote:
Waarom noemt php het dan ook unlink ipv delete
Maar dit zal noobs helpen (hoop ik)
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Omdat delete() ook voor directory's is (dan roept die eigenlijk rmdir() op) unlink is enkel voor files.quote:
Waarom noemt php het dan ook unlink ipv delete
http://stackoverflow.com/a/15124886
Omdat je de inode pointer breekt en dus de link verbreekt. Je verwijderd de file niet, maar de link naar de file.quote:
Waarom noemt php het dan ook unlink ipv delete
http://perldoc.perl.org/functions/unlink.html
http://linux.die.net/man/2/unlink
In theory there is no difference between theory and practice. In practice there is.
Mijn opmerking was eigenlijk meer een sneer naar php. Ik vond het wel ironisch dat de manual poogt grappig te zijn door te impliceren dat de php-functieset logisch in elkaar zit. Ze jatten functies en conventies van verschillende talen bij elkaar - waaronder inderdaad van C.
Unlink() is een Posix-functie en is een variant op de C-functie remove(). Over het algemeen zijn C runtime functies zoals remove() meer portable dan Posix-functies. Beide functies bestaan overigens in de C runtime headers in Windows. Dat del een dos-commando is en unlink een Linux commandlinefunctie heeft er verder weinig mee te maken, omdat dat system utilities zijn en geen C/Posix-functies.quote:Op donderdag 9 januari 2014 03:07 schreef Chandler het volgende:
[..]
Volgens mij staat dat aardig beschreven, omdat de unlink functie ook in C gebruikt wordt... oh en delete oftewel del is een 'dos' commando
Maar dit zal noobs helpen (hoop ik)
Het klopt inderdaad dat unlink() (en ook remove()) alleen bestanden kunnen 'verwijderen'. System utilities als del (delete zit niet in ms-dos) hebben weinig te maken met de C/Posix-functies.quote:
[..]
Omdat delete() ook voor directory's is (dan roept die eigenlijk rmdir() op) unlink is enkel voor files.
http://stackoverflow.com/a/15124886
Klopt, maar in ruime zin mag het bestand na unlink niet meer (op normale wijze) vindbaar zijn. Voor een taal als php maakt het niet veel uit of het beestje nu unlink, delete, erase of remove heet, omdat het enige doel het 'verwijderen' van het bestand is. Hoe dat low-level gebeurt is voor een taal als php niet interessant, zolang het maar portable is en een consistent gedrag vertoont tussen de verschillende besturingssystemen. Zoals ik hierboven al zei kunnen ze dan beter focussen op een consiste naming convention ipv bij verschillende talen wat functienamen bij elkaar te grabbelen.quote:
[..]
Omdat je de inode pointer breekt en dus de link verbreekt. Je verwijderd de file niet, maar de link naar de file.
http://perldoc.perl.org/functions/unlink.html
http://linux.die.net/man/2/unlink
PHP is gebasseerd op Perl, en in perl heet het unlink en Perl is weer in C geschreven, waar het ook unlink is. Dus de naming convention is correct.quote:
Klopt, maar in ruime zin mag het bestand na unlink niet meer (op normale wijze) vindbaar zijn. Voor een taal als php maakt het niet veel uit of het beestje nu unlink, delete, erase of remove heet, omdat het enige doel het 'verwijderen' van het bestand is. Hoe dat low-level gebeurt is voor een taal als php niet interessant, zolang het maar portable is en een consistent gedrag vertoont tussen de verschillende besturingssystemen. Zoals ik hierboven al zei kunnen ze dan beter focussen op een consiste naming convention ipv bij verschillende talen wat functienamen bij elkaar te grabbelen.
Ik ben het 100% met je eens dat ze in PHP een betere conventie moeten gaan hanteren, idem voor needle-haystack conventies, maar om dan unlink als voorbeeld te nemen is ridicuul.
In theory there is no difference between theory and practice. In practice there is.
Ze zouden voor PHP6 of 7 gewoon een goeie naming convention moeten ontwerpen, en al die duizenden aliases de deur uit doen.
eensch.quote:
Ze zouden voor PHP6 of 7 gewoon een goeie naming convention moeten ontwerpen, en al die duizenden aliases de deur uit doen.
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? 
“Specialization is for insects”.—Robert Heinlein
Dat is historisch zo gegroeid inderdaad, maar dat wil niet zeggen dat de naming convention in php als geheel klopt (waar het me om ging). Ik denk dat iedereen deze inmiddels wel kent: PHP: a fractal of bad designquote:
[..]
PHP is gebasseerd op Perl, en in perl heet het unlink en Perl is weer in C geschreven, waar het ook unlink is. Dus de naming convention is correct.
Dan heb je mijn eerste alinea niet gelezenquote:Ik ben het 100% met je eens dat ze in PHP een betere conventie moeten gaan hanteren, idem voor needle-haystack conventies, maar om dan unlink als voorbeeld te nemen is ridicuul.
Het ging me niet om unlink, maar om de manualuitleg onder het kopje 'delete'. Wat ik in reactie op jou er even uit wilde lichten is dat de low-level implementatie van een deletiefunctie in een high-level taal als php geen rol mag spelen, zolang het maar doet wat het moet doen: een bestand verwijderen.quote:
Mijn opmerking was eigenlijk meer een sneer naar php. Ik vond het wel ironisch dat de manual poogt grappig te zijn door te impliceren dat de php-functieset logisch in elkaar zit. Ze jatten functies en conventies van verschillende talen bij elkaar - waaronder inderdaad van C.
Weet iemand nog goede Project Management Software die ik lokaal kan draaien (web based)?
Open source het liefst.
Ik heb natuurlijk het een en ander uitgezocht, maar net niet echt gevonden wat ik zoek.
Wat helemaal tof zou zijn is iets als activecollab
Maar daar moet je voor betalen.
Open source het liefst.
Ik heb natuurlijk het een en ander uitgezocht, maar net niet echt gevonden wat ik zoek.
Wat helemaal tof zou zijn is iets als activecollab
Maar daar moet je voor betalen.
Je moeder is een hamster
Wat werkt er precies niet?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?
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:
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
