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.
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:Op vrijdag 10 januari 2014 22:23 schreef zoem het volgende:
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:Op zaterdag 11 januari 2014 19:21 schreef n8n het volgende:
[..]
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.
Nice, over sql gesproken, deze kerel is echt een baas: http://code.openark.org/blog/mysql/sql-pie-chartquote:Op maandag 13 januari 2014 10:33 schreef Aether het volgende:
Vond dit wel een aardige verzameling, misschien heeft iemand er nog iets aan:
Artful Common MySQL Queries.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Wat een monsterqueryquote:
[..]
Nice, over sql gesproken, deze kerel is echt een baas: http://code.openark.org/blog/mysql/sql-pie-chart
Ik heb keer een stored procedure van iets van 600 regels geschrevenquote:
Was iets met een grote huizensite zeg maar
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
599 Regels commentaar?quote:
[..]
Ik heb keer een stored procedure van iets van 600 regels geschreven
Was iets met een grote huizensite zeg maar
Nee was de searchquery maar daarin ook nog eens het hele paging en parameter mechanisme, pfffff hoofdpijn van dat ding.quote:
Op
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
https://github.com/Shandem/Examine ?quote:
[..]
Nee was de searchquery maar daarin ook nog eens het hele paging en parameter mechanisme, pfffff hoofdpijn van dat ding.
We spreken hier over 2001, toen waren dat soort technieken nog niet zo gebruikelijk, wat we wel deden was de database readonly maken, dat scheelt ongeveer 40 procent. Tegenwoordig gebruik je voor dit soort zaken gewoon een noSql server of anders wel een ORM mapper.quote:
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Ah, dat plaatst het wat in de context, als je een sp van 600 regels maakt moet er toch een lampje gaan branden. The horror!quote:
[..]
We spreken hier over 2001, toen waren dat soort technieken nog niet zo gebruikelijk, wat we wel deden was de database readonly maken, dat scheelt ongeveer 40 procent. Tegenwoordig gebruik je voor dit soort zaken gewoon een noSql server of anders wel een ORM mapper.
Yay Apache, MySQL en de laatste versie van php werken op m'n Macbook. Heb nu alleen dat als ik een pagina met een MySQL refresh het laden lang duurt. ~2 seconden gebeurt er niks en dan is alles er binnen een oogwenk. Waar moet ik dit zoeken?
edit: het duurt maar liefst 5.0075240135193 seconden vrij consistent ook
edit2: via stackoverflow mn host info veranderd naar good old 127.0.0.1 en nu werkt het in 0.0031747817993164 seconden. Beter
edit: het duurt maar liefst 5.0075240135193 seconden
vrij consistent ookedit2: via stackoverflow mn host info veranderd naar good old 127.0.0.1 en nu werkt het in 0.0031747817993164 seconden. Beter
“Specialization is for insects”.—Robert Heinlein
Ben ik weer. Om in een functie specifieke $_POST input te krijgen moest ik of telkens voluit $_POST['name'] schrijven, er een variabele van maken of variabelen global aanroepen. Heb nu een functie die je overal kan aanroepen die de $_POST data omzet in losse variabelen die je lokaal kan gebruiken.
het maakt van elke key in een array een variable met de naam en waarde van de key. dus $_POST[email] wordt omgezet naar $email = 'waarde van email'. Als een waarde leeg is heeft de variabele een null waarde.
Op of aanmerkingen? Kom net kijken dus heb vaak het idee dat ik met ideeën kom
| 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 28 29 30 | <?php // fictieve $_POST array $post = array('email' => 'hoi', 'password' => 'test'); function get_variables($data) { $key = 0; do { $keys = array_keys($data); $var = (array_keys($data)[$key]); global $$var; if (!empty($data[$var])) { $$var = $data[$var]; } else { $$var = null; } $key++; } while (array_key_exists($key, $keys)); } // hier wil ik $_POST gaan gebruiken get_variables($post); // variabelen komen uit de functie echo "$email<br>$password"; ?> |
Op of aanmerkingen? Kom net kijken dus heb vaak het idee dat ik met
ideeën kom
“Specialization is for insects”.—Robert Heinlein
Global vind ik zelf niet zo netjes. Ik zou het via een class (service) doen.quote:Op maandag 13 januari 2014 18:59 schreef n8n het volgende:
Ben ik weer. Om in een functie specifieke $_POST input te krijgen moest ik of telkens voluit $_POST['name'] schrijven, er een variabele van maken of variabelen global aanroepen. Heb nu een functie die je overal kan aanroepen die de $_POST data omzet in losse variabelen die je lokaal kan gebruiken.
[ code verwijderd ]
het maakt van elke key in een array een variable met de naam en waarde van de key. dus $_POST[email] wordt omgezet naar $email = 'waarde van email'. Als een waarde leeg is heeft de variabele een null waarde.
Op of aanmerkingen? Kom net kijken dus heb vaak het idee dat ik met
global is toch nodig om de variabele überhaupt te kunnen definiëren buiten de scope van de function (of class)?quote:
[..]
Global vind ik zelf niet zo netjes. Ik zou het via een class (service) doen.
“Specialization is for insects”.—Robert Heinlein
Bij een class heb je global niet nodig. Als je het object eenmaal hebt aangemaakt kun je dat meegeven aan je functies. Ook kun je op jouw manier variabelen per ongeluk overschrijven als je dezelfde namen ergens anders gebruikt.quote:
[..]
global is toch nodig om de variabele überhaupt te kunnen definiëren buiten de scope van de function (of class)?
dus variabelen die je binnen je class (maar buiten een functie aanmaakt) kan je binnen die class in elke functie gebruiken? Ga dat even proberen. Zou wel mooi zijn met het oog op overschrijven van bestaande waarden.quote:Op maandag 13 januari 2014 19:05 schreef bondage het volgende:
[..]
Bij een class heb je global niet nodig. Als je het object eenmaal hebt aangemaakt kun je dat meegeven aan je functies. Ook kun je op jouw manier variabelen per ongeluk overschrijven als je dezelfde namen ergens anders gebruikt.
“Specialization is for insects”.—Robert Heinlein
Dit is niet echt een goede oplossing. Veel te onveilig, je kunt zelf post variabelen toevoegen en die worden dan als variabele gebruikt. Dit is een paar jaar geleden een grote overstap geweest voor mensen. register_globals stond vaak aan en gaf superveel beveiligingslekken. Je hebt nu een zelfde soort functie geschreven.quote:
Ben ik weer. Om in een functie specifieke $_POST input te krijgen moest ik of telkens voluit $_POST['name'] schrijven, er een variabele van maken of variabelen global aanroepen. Heb nu een functie die je overal kan aanroepen die de $_POST data omzet in losse variabelen die je lokaal kan gebruiken.
[ code verwijderd ]
het maakt van elke key in een array een variable met de naam en waarde van de key. dus $_POST[email] wordt omgezet naar $email = 'waarde van email'. Als een waarde leeg is heeft de variabele een null waarde.
Op of aanmerkingen? Kom net kijken dus heb vaak het idee dat ik met
