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:Op maandag 13 januari 2014 19:33 schreef totalvamp het volgende:
[..]
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 ]
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:Op maandag 13 januari 2014 19:44 schreef bondage het volgende:
[..]
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.
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 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:Op maandag 13 januari 2014 19:50 schreef totalvamp het volgende:
[..]
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.
Ja misschien inderdaad te geavanceerd voor een beginnerquote:Op maandag 13 januari 2014 20:10 schreef bondage het volgende:
[..]
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.
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(); ?> |
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:Op maandag 13 januari 2014 19:33 schreef totalvamp het volgende:
[..]
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:Op maandag 13 januari 2014 20:43 schreef Light het volgende:
[..]
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:Op maandag 13 januari 2014 20:43 schreef Light het volgende:
[..]
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:Op maandag 13 januari 2014 21:32 schreef bondage het volgende:
[..]
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 post Namespaces moet ik me toch maar eens in gaan verdiepen, werkelijk nog nooit gebruiktquote:Op maandag 13 januari 2014 21:34 schreef Light het volgende:
[..]
Tegenwoordig heeft PHP namespaces om dat soort conflicten te voorkomen.
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:Op maandag 13 januari 2014 20:43 schreef Light het volgende:
[..]
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:Op maandag 13 januari 2014 21:32 schreef bondage het volgende:
[..]
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.
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:Op maandag 13 januari 2014 22:21 schreef zoem het volgende:
[..]
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.
Zeker, gewoon ermee aan de slag gaan werkt het bestequote:Op maandag 13 januari 2014 22:26 schreef bondage het volgende:
[..]
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:Op maandag 13 januari 2014 22:35 schreef zoem het volgende:
[..]
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:Op maandag 13 januari 2014 22:49 schreef bondage het volgende:
[..]
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:Op dinsdag 14 januari 2014 11:43 schreef zoem het volgende:
[..]
Deze code
[ code verwijderd ]
is hetzelfde als dit
[ code verwijderd ]
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:Op maandag 13 januari 2014 22:35 schreef zoem het volgende:
[..]
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:Op dinsdag 14 januari 2014 21:15 schreef Light het volgende:
[..]
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 beeld Was even uit praktische overweging.quote:request_order string
If this directive is not set, variables_order is used for $_REQUEST contents.
Ik vind het nogal lelijk in php eerlijk gezegdquote:Op maandag 13 januari 2014 21:34 schreef Light het volgende:
[..]
Tegenwoordig heeft PHP namespaces om dat soort conflicten te voorkomen.
Waarom precies?quote:Op woensdag 15 januari 2014 17:41 schreef wipes66 het volgende:
[..]
Ik vind het nogal lelijk in php eerlijk gezegd
namespaces zijn juist een verademing en ik word er blij van in de codequote:Op woensdag 15 januari 2014 20:47 schreef wipes66 het volgende:
[..]
Omdat het net lijkt of je een letter escaped zeg maar.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |