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.
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
niet eens aan gedachtquote:
[..]
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.
dan zou het eventueel nog met een werken als ik een prefix toevoeg zodat overschrijven van bestaande variabelen (door kwaadwillenden) geen optie meer is. Toch blij dat ik het even heb nagevraagd. global haal ik sowieso wel weg dan [ Bericht 0% gewijzigd door n8n op 13-01-2014 19:27:03 ]
“Specialization is for insects”.—Robert Heinlein
Alles wat je in een class buiten de functie zet is beschikbaar binnen de functies die in die class staan.quote:
[..]
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.
Voorbeeld:
private $variable_1 = 'test';
private $variable_2 = 'test2';
public function testFunctie() {
echo $this->variable_1 . '<br /> . $this->variable_2';
}
ah in 1 keer snap ik $this, heb ik meteen m'n prefix te pakkenquote:
[..]
Alles wat je in een class buiten de functie zet is beschikbaar binnen de functies die in die class staan.
Voorbeeld:
private $variable_1 = 'test';
private $variable_2 = 'test2';
public function testFunctie() {
echo $this->$variable_1 . '<br /> . $this->$variable_2';
}
“Specialization is for insects”.—Robert Heinlein
$this is de referentie naar de class waar je momenteel in zit (of inherit).quote:
[..]
ah in 1 keer snap ik $this, heb ik meteen m'n prefix te pakken
Voor statische vars is dit self::
[ Bericht 2% gewijzigd door #ANONIEM op 13-01-2014 19:15:37 ]
Zie editquote:
[..]
ah in 1 keer snap ik $this, heb ik meteen m'n prefix te pakken
$this->variable_1 (dollarteken hoort niet voor de var)
ze maken het wel makkelijkquote:
[..]
$this is de referentie naar de class waar je momenteel in zit (of inherit).
Voor statische vars is dit self::
“Specialization is for insects”.—Robert Heinlein
ja precies, nu weer uitdokteren hoe ik m'n idee alsnog werkend krijg want het is niet echt DRY als ik overal globals moet definiėren.quote:
[..]
Zie edit
$this->variable_1 (dollarteken hoort niet voor de var)
“Specialization is for insects”.—Robert Heinlein
Zoiets zou je mee kunnen beginnen:quote:
[..]
ja precies, nu weer uitdokteren hoe ik m'n idee alsnog werkend krijg want het is niet echt DRY als ik overal globals moet definiėren.
| 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 31 | <?php class cRequest { private $request_vars; public function __construct() { $this->request_vars = $_REQUEST; } public function setRequestVar($v_key, $v_val) { $this->request_vars[$v_key] = $v_val; } public function getRequestVar($key, $ret_nonexisting = '') { if(isset($this->request_vars[$key])) { return $this->request_vars[$key]; } return $ret_nonexisting; } public function getRequestArray() { return $this->request_vars; } } ?> <?php $obj_request = new cRequest(); // print de var, als deze niet bestaat dan krijg je 'ik_was_undefined' terug. echo $obj_request->getRequestVar('bla', 'ik_was_undefined'); ?> |
Dit werkt dan ook:
| 1 2 3 4 5 6 7 | <?php echo testFunction($obj_request); function testFunction($request_object) { return $request_object->getRequestVar('bla', 'ik_was_undefined'); } ?> |
Dit is niet de beste oplossing, je classe is een beetje ouderwets en je kunt dan beter gebruik maken van de magic get en set methoden. Dat scheelt ook gelijk in wat je moet typen.quote:
[..]
Zoiets zou je mee kunnen beginnen:
[ code verwijderd ]
| 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 31 | <?php class cRequest { private $request_vars; public function __construct() { $this->request_vars = $_REQUEST; } public function __set($v_key, $v_val) { $this->request_vars[$v_key] = $v_val; } public function __get($key) { if(isset($this->request_vars[$key])) { return $this->request_vars[$key]; } return false; } public function getRequestArray() { return $this->request_vars; } } ?> <?php $obj_request = new cRequest(); // krijg een var of false echo $obj_request->bla; ?> |
[ Bericht 1% gewijzigd door #ANONIEM op 13-01-2014 19:33:52 ]
