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.
niet eens aan gedachtquote:Op maandag 13 januari 2014 19:08 schreef totalvamp het volgende:
[..]
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:Op maandag 13 januari 2014 19:08 schreef n8n het volgende:
[..]
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:Op maandag 13 januari 2014 19:14 schreef n8n het volgende:
[..]
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:Op maandag 13 januari 2014 19:15 schreef bondage het volgende:
[..]
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 ]
Heel erg bedankt heren, ik moet het nu even 500 keer lezen voordat ik het door heb Zit nog in de fase dat ik van de ene naar de andere error vraag op stack overflow browse
heb nu bezoek (yay maar helaas). Morgen weer verder puzzlen
Zit nog in de fase dat ik van de ene naar de andere error vraag op stack overflow browseheb nu bezoek (yay maar helaas). Morgen weer verder puzzlen
“Specialization is for insects”.—Robert Heinlein
Dat had ik in de eerste instantie maar dan kun je niet bepalen wat er moet worden teruggegeven indien de var niet voorkomt in de globale request array.quote:
[..]
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.
[ code verwijderd ]
Stel dat je een form hebt en je wilt vooraf ingevulde waarden hebben als er geen input van de gebruiker is doorgegeven, via de functie getRequestVar in mijn class kun je dan via de tweede param aangeven wat deze waarde moet zijn. Op jouw manier lukt dat niet, of ik moet iets over het hoofd zien. Ook kun je de functie uitbreiden met een extra param waarin je bijvoorbeeld mee kunt geven of je de waarde om wilt zetten in htmlentities, dan hoef je die functie niet los aan te roepen in je template.
Ik begreep inderdaad dat je iets specifieks terug wilde hebben. Dat is alleen niet de taak van deze class. Je geeft alleen iets terug en in je Template class of Controller zul je daar iets mee moeten doen.quote:
[..]
Dat had ik in de eerste instantie maar dan kun je niet bepalen wat er moet worden teruggegeven indien de var niet voorkomt in de globale request array.
Stel dat je een form hebt en je wilt vooraf ingevulde waarden hebben als er geen input van de gebruiker is doorgegeven, via de functie getRequestVar in mijn class kun je dan via de tweede param aangeven wat deze waarde moet zijn. Op jouw manier lukt dat niet, of ik moet iets over het hoofd zien. Ook kun je de functie uitbreiden met een extra param waarin je bijvoorbeeld mee kunt geven of je de waarde om wilt zetten in htmlentities, dan hoef je die functie niet los aan te roepen in je template.
Bijvoorbeeld:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | <?php $t = new Template('test'); $r = new Request(); $t->replace('email', $r->email); class Template { protected $html; public function replace($key, $with) { if(false !== $with) $this->html = str_replace($key, $with, $this->html); // Hier kun je afhandelen wat je doet als het false is } } |
Ik moet er wel bij zeggen dat ik mijn formulieren opbouw met classes. Elk element is een class met zijn eigen validatie en manier om standaardwaarde te zetten.
[ Bericht 1% gewijzigd door #ANONIEM op 13-01-2014 20:00:07 ]
Ik ben het met je eens dat je dit soort zaken in de template zelf af hoort te handelen, echter vind ik het zelf wel handig dat de request class het in dit geval ook kan omdat je de waarden niet altijd in de template gebruikt maar misschien ook ergens anders. Je zou dit natuurlijk ook door die classes (bijv. een formulier verwerking class) laten afhandelen maar dat vond ik voor het voorbeeldje iets te diep op de stof ingaan.quote:
[..]
Ik begreep inderdaad dat je iets specifieks terug wilde hebben. Dat is alleen niet de taak van deze class. Je geeft alleen iets terug en in je Template class of Controller zul je daar iets mee moeten doen.
Bijvoorbeeld:
[ code verwijderd ]
Ik moet er wel bij zeggen dat ik mijn formulieren opbouw met classes. Elk element is een class met zijn eigen validatie en manier om standaardwaarde te zetten.
Ik bouw in de meeste tools/websites die ik heb geschreven de template op als een extension op een baseclass en set dan alle vars die nodig zijn in de template. Je kunt daar dan eventueel ook standaardwaarden zetten.
Ja misschien inderdaad te geavanceerd voor een beginnerquote:
[..]
Ik ben het met je eens dat je dit soort zaken in de template zelf af hoort te handelen, echter vind ik het zelf wel handig dat de request class het in dit geval ook kan omdat je de waarden niet altijd in de template gebruikt maar misschien ook ergens anders. Je zou dit natuurlijk ook door die classes (bijv. een formulier verwerking class) laten afhandelen maar dat vond ik voor het voorbeeldje iets te diep op de stof ingaan.
Ik bouw in de meeste tools/websites die ik heb geschreven de template op als een extension op een baseclass en set dan alle vars die nodig zijn in de template. Je kunt daar dan eventueel ook standaardwaarden zetten.
Ookal gebruik je de request ergens anders, zou je eigenlijk nog steeds een false moeten teruggeven als standaard. Wat gebeurd er nu als je de request class gebruikt om een database te vullen. Dan vult hij de waardes met een string ookal bestaat de waarde niet.
Normaal heb je natuurlijk iets van validatie, maar deze stap zou je al over kunnen slaan als de waarde false is. Al heeft dit waarschijnlijk weinig nut in jouw opzet.
Ik hou zelf de regel aan dat ik of een string/array/object teruggeef of een false. En uiteindelijk in de Controller de waarschuwing ervan laat zien als dat nodig is.
Dit is even een voorbeeld hoe ik zelf een form opbouw:
| 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 $f = new System\Core\Form(); $f->addElement(new System\Core\Form\Element\Fieldset( array( 'name' => 'testFieldset', 'label' => 'Testfieldset', 'elements' => array( new System\Core\Form\Input\Text(array( 'name' => 'test', 'label' => 'Test field', 'value' => 'testvaluess', 'validator' => array( 'Length' => array('max' => 10) ))), new System\Core\Form\Input\Text(array( 'name' => 'test', 'label' => 'Testfield', 'value' => 'testvaluess', 'validator' => array( 'Length' => array('max' => 10) ))) )) )); $f->addElement(new System\Core\Form\Element\Button( array( 'name' => 'Test', 'value' => 'Test' ) )); $f->show(); ?> |
De form wordt op de post pagina dan gevalideerd
[ Bericht 33% gewijzigd door #ANONIEM op 13-01-2014 20:31:33 ]
Ik zou het zo maken dat de constructor een array accepteert, zodat je dezelfde class ook voor $_GET en $_POST kunt gebruiken. En zodat je de code makkelijker kunt testen. En classes waarvan de naam begint met een kleine letter c snap ik ook niet.quote:
[..]
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.
[ code verwijderd ]
| 1 2 3 4 5 6 7 8 9 10 11 | <?php class cRequest { private $request_vars; public function __construct($vars = $_REQUEST) { $this->request_vars = $vars; } // meer functies } ?> |
Wat dat betreft kun je eigenlijk ook gewoon gelijk de $_REQUEST gebruiken. Dan kun je de class als static gebruiken.quote:
[..]
Ik zou het zo maken dat de constructor een array accepteert, zodat je dezelfde class ook voor $_GET en $_POST kunt gebruiken. En zodat je de code makkelijker kunt testen. En classes waarvan de naam begint met een kleine letter c snap ik ook niet.
[ code verwijderd ]
Dat is mij zo aangeleerd tijdens een cursus OOP ergens in een ver verleden, volgens mij om ervoor te zorgen dat je niet met gereserveerde namen komt te zitten. Je zou er eventueel ook iets anders voor kunnen zetten natuurlijk.quote:
[..]
En classes waarvan de naam begint met een kleine letter c snap ik ook niet.
Tegenwoordig heeft PHP namespaces om dat soort conflicten te voorkomen.quote:
[..]
Dat is mij zo aangeleerd tijdens een cursus OOP ergens in een ver verleden, volgens mij om ervoor te zorgen dat je niet met gereserveerde namen komt te zitten. Je zou er eventueel ook iets anders voor kunnen zetten natuurlijk.
Je UI past goed bij deze postquote:
[..]
Tegenwoordig heeft PHP namespaces om dat soort conflicten te voorkomen.
Namespaces moet ik me toch maar eens in gaan verdiepen, werkelijk nog nooit gebruikt 
Wat is trouwens je redenatie daarachter? Ik had juist voor $_REQUEST gekozen omdat deze zowel de GET als POST waarden bevat. Ik doe het eigenlijk altijd zo en ben nog nooit tegen problemen aangelopen.quote:
[..]
Ik zou het zo maken dat de constructor een array accepteert, zodat je dezelfde class ook voor $_GET en $_POST kunt gebruiken.
Dat is (een variant op) de Hungarian notation en stamt uit de tijd dat data types niet snel herkend konden worden in de code. In php vind ik dergelijke type hints (want dat zijn het) overbodig, want 1) php is weak typed en 2) een goede IDE geeft ook hints. Je ziet ook dat deze notatie niet (meer) gebruikt wordt in de bekende frameworks en projecten zoals ZF, Symfony, Doctrine, Laravel en vele anderen.quote:
[..]
Dat is mij zo aangeleerd tijdens een cursus OOP ergens in een ver verleden, volgens mij om ervoor te zorgen dat je niet met gereserveerde namen komt te zitten. Je zou er eventueel ook iets anders voor kunnen zetten natuurlijk.
Zoals Light al aangeeft heb je nu namespaces. Moderne frameworks maken daar al dankbaar gebruik van. Hiervoor zag je veelvuldig de underscore-notatie (bijv Zend_View_Helper_Abstract) om conflicten te voorkomen. In beide constructies wordt de projectnaam als primaire prefix/namespace gebruikt.
Ik ben al wat sites aan het doornemen over namespaces; lijkt niet heel ingewikkeld als ik het zo zie. Binnenkort zelf maar even wat mee gaan experimenteren. Je leert immers het snelst door het gewoon te doenquote:
[..]
Dat is (een variant op) de Hungarian notation en stamt uit de tijd dat data types niet snel herkend konden worden in de code. In php vind ik dergelijke type hints (want dat zijn het) overbodig, want 1) php is weak typed en 2) een goede IDE geeft ook hints. Je ziet ook dat deze notatie niet (meer) gebruikt wordt in de bekende frameworks en projecten zoals ZF, Symfony, Doctrine, Laravel en vele anderen.
Zoals Light al aangeeft heb je nu namespaces. Moderne frameworks maken daar al dankbaar gebruik van. Hiervoor zag je veelvuldig de underscore-notatie (bijv Zend_View_Helper_Abstract) om conflicten te voorkomen. In beide constructies wordt de projectnaam als primaire prefix/namespace gebruikt.
Nadeel is dat $_REQUEST de data uit $_GET, $_POST en $_COOKIE combineert. Dat creëert 2 potentiele problemen:quote:Op maandag 13 januari 2014 21:56 schreef bondage het volgende:
[..]
Wat is trouwens je redenatie daarachter? Ik had juist voor $_REQUEST gekozen omdat deze zowel de GET als POST waarden bevat. Ik doe het eigenlijk altijd zo en ben nog nooit tegen problemen aangelopen.
1) De data van $_COOKIE, $_POST en $_GET overschrijven elkaar als er dezelfde keys bestaan, wat kan leiden tot onverwacht gedrag. De standaarvolgorde is G, P en dan C.
2) Omdat $_COOKIE voorrang heeft op $_GET en $_POST, kan er mogelijk cookiedata op onveilige plekken terechtkomen.
NB: De volgorde en de aanwezigheid van cookiedata hangt af van de php.ini directives.
Zeker, gewoon ermee aan de slag gaan werkt het bestequote:
[..]
Ik ben al wat sites aan het doornemen over namespaces; lijkt niet heel ingewikkeld als ik het zo zie. Binnenkort zelf maar even wat mee gaan experimenteren. Je leert immers het snelst door het gewoon te doen
Ai, dat is best wel naatje. Het zal waarschijnlijk niet zo snel voorkomen omdat ik erg goed let op de naamgeving van mijn cookie, post en get vars door er iets voor te zetten maar je weet echter maar nooit... Binnenkort maar ff mijn request classes gaan verbouwenquote:
[..]
Nadeel is dat $_REQUEST de data uit $_GET, $_POST en $_COOKIE combineert. Dat creëert 2 potentiele problemen:
1) De data van $_COOKIE, $_POST en $_GET overschrijven elkaar als er dezelfde keys bestaan, wat kan leiden tot onverwacht gedrag. De standaarvolgorde is G, P en dan C.
2) Omdat $_COOKIE voorrang heeft op $_GET en $_POST, kan er mogelijk cookiedata op onveilige plekken terechtkomen.
Dit is mijnequote:
[..]
Ai, dat is best wel naatje. Het zal waarschijnlijk niet zo snel voorkomen omdat ik erg goed let op de naamgeving van mijn cookie, post en get vars door er iets voor te zetten maar je weet echter maar nooit... Binnenkort maar ff mijn request classes gaan verbouwen
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?php namespace System\Helpers; class Request { public static function isPost() { return ($_SERVER['REQUEST_METHOD'] == 'POST')?true:false; } public static function get($key) { return isset($_GET[$key])?$_GET[$key]:false; } public static function post($key) { return isset($_POST[$key])?$_POST[$key]:false; } } ?> |
Deze codequote:
| 1 2 3 | <?php return ($_SERVER['REQUEST_METHOD'] == 'POST')?true:false; ?> |
| 1 2 3 | <?php return $_SERVER['REQUEST_METHOD'] == 'POST'; ?> |
Heel erg waarquote:
[..]
Deze code
[ code verwijderd ]
is hetzelfde als dit
[ code verwijderd ]
Ik copy paste vaak mijn oudere classes aangezien de functionaliteit hetzelfde blijft
wel een erg domme 'fout'.
Je linkt naar de ini directive variables_order, terwijl eigenlijk request_order wordt gebruikt om $_REQUEST te vullen. In beide kun je ook E en S vinden (Environment en Server).quote:
[..]
Nadeel is dat $_REQUEST de data uit $_GET, $_POST en $_COOKIE combineert. Dat creëert 2 potentiele problemen:
1) De data van $_COOKIE, $_POST en $_GET overschrijven elkaar als er dezelfde keys bestaan, wat kan leiden tot onverwacht gedrag. De standaarvolgorde is G, P en dan C.
2) Omdat $_COOKIE voorrang heeft op $_GET en $_POST, kan er mogelijk cookiedata op onveilige plekken terechtkomen.
NB: De volgorde en de aanwezigheid van cookiedata hangt af van de php.ini directives.
Heb je helemaal gelijk in, maar:quote:
[..]
Je linkt naar de ini directive variables_order, terwijl eigenlijk request_order wordt gebruikt om $_REQUEST te vullen. In beide kun je ook E en S vinden (Environment en Server).
Met variables_order als anchor staan ze allebei in beeldquote:request_order string
If this directive is not set, variables_order is used for $_REQUEST contents.
Was even uit praktische overweging.
