Makkelijk gebruik Globals
Door Iltar van der berg, 20 jaar geleden, 4.107x bekeken
Ik maak hier gebruik van 2 Design patterns; Factory en Singleton. Ik heb hierbij 2 voorbeelden, Get en Post (je kan het bv ook voor sessions maken). Het is heel gemakkelijk in gebruik. Je kan het met of zonder factory gebruiken.
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
// Met factory:
Berg_Globals::post('client_name');
//Of zonder:
Berg_Globals_Post::instance()->client_name;
//Bijden komen neer op:
(isset($_POST['client_name']) ? $_POST['client_name'] : '');
?>
// Met factory:
Berg_Globals::post('client_name');
//Of zonder:
Berg_Globals_Post::instance()->client_name;
//Bijden komen neer op:
(isset($_POST['client_name']) ? $_POST['client_name'] : '');
?>
Zoals je ziet gebruik ik hier dezelfde namespacing als Zend en sommige andere frameworks. Dit kan je dus Naast zend gebruiken met dezelfde autoloader! Ik gebruik dezelfde soort methode in mijn framework (kan namelijk naast zend draaien)
Overigens lijkt de factory een beetje dubbelop, dit is echter niet het geval aangezien je er zelf nu nog wat aan kan sleutelen (bv een session controller aan hangen)
Gesponsorde koppelingen
PHP script bestanden
Er zijn 14 reacties op 'Makkelijk gebruik globals'
0 
-0 
-0
Tuurlijk niet... Kijk bij de comments, en zie wat private doet tov public.
0 -0
-0
Eigenlijk moet je ze nog final maken ook...
Anders zou je ze kunnen omzeilen als je de class extend...
het is trouwens gewoon:
En waarom geef je '' terug? kan je net zo goed null doen...
Verder valt dit bij mij onder Request variabelen, ik vind Global meer klinken als $_GLOBAL[]; en daar ben ik niet zo'n voorstander van!!!
Waarom maak je ook 2 gelijke classes voor Get en Post? Dan kan je beter 1 abstracte maken lijkt me...
Ook mis ik plugins e.d. voor bijvoorbeeld magic quotes e.d.
En $_Files moet je nog doen....
Anders zou je ze kunnen omzeilen als je de class extend...
het is trouwens gewoon:
En waarom geef je '' terug? kan je net zo goed null doen...
Verder valt dit bij mij onder Request variabelen, ik vind Global meer klinken als $_GLOBAL[]; en daar ben ik niet zo'n voorstander van!!!
Waarom maak je ook 2 gelijke classes voor Get en Post? Dan kan je beter 1 abstracte maken lijkt me...
Ook mis ik plugins e.d. voor bijvoorbeeld magic quotes e.d.
En $_Files moet je nog doen....
0 -0
-0
Ik geef '' terug, omdat een standaard value van een get of post altijd een string is.
Globals = verzamel naam voor globale variable daarom globals ;)
hm ja dat abstracte hb je gelijk in, ga ik even veranderen.
Magic quotes als plugin ? hoe bedoel je plugins precies?
Ja, ik ga ook nog aan de slag met de overige.
Globals = verzamel naam voor globale variable daarom globals ;)
hm ja dat abstracte hb je gelijk in, ga ik even veranderen.
Magic quotes als plugin ? hoe bedoel je plugins precies?
Ja, ik ga ook nog aan de slag met de overige.
0 -0
-0
Je zou kunnen overwegen een extra parameter met de standaard return value mee te geven (optioneel) dan kan je zelf kiezen of je een lege string, null of misschien zelfs nog iets anders terug wil.
Edit:
Daar sluit ik me bij aan.
Edit:
Quote:
Waarom maak je ook 2 gelijke classes voor Get en Post? Dan kan je beter 1 abstracte maken lijkt me...
Daar sluit ik me bij aan.
0 -0
-0
Nou voor GPC zou je eventueel een magic_quotes filter kunnen maken...
//bitwise idee ?
Berg_Globals::filter(new Berg_Globals_Filter_Magic(), Berg_Globals::Get | Berg_Globals::Post | Berg_Globals::Cookie)
//get zou je dan ook ziets kunnen maken nog eventueel....
Berg_Globals::get(Berg_Globals::Post)->client_name;
Voor $_FILES, een serializer voor image[] arrays.
Voor $_SERVER vars een strip_tags / htmlentities filter ?
//bitwise idee ?
Berg_Globals::filter(new Berg_Globals_Filter_Magic(), Berg_Globals::Get | Berg_Globals::Post | Berg_Globals::Cookie)
//get zou je dan ook ziets kunnen maken nog eventueel....
Berg_Globals::get(Berg_Globals::Post)->client_name;
Voor $_FILES, een serializer voor image[] arrays.
Voor $_SERVER vars een strip_tags / htmlentities filter ?
0 -0
-0
Hoe bedoel je dan filter, wat moet je filteren :P
magic quotes hoord uit te staan, oke, optie op dat te filteren, maar wat zou je dan nog meer moeten filteren XD
magic quotes hoord uit te staan, oke, optie op dat te filteren, maar wat zou je dan nog meer moeten filteren XD
0 -0
-0
Ik wil geen spelbreker zijn, maar voor dit hele principe bestaat het begrip "Registry", zoals Zend_Registry. Wat jij hier bouwt is een (simpele) registry. Bestaande registry's hebben meestal al ArrayAccess enzo ingebouwd, dat zou je ook kunnen doen (zie Zend).
Even nog ter bevordering van het OOP-denken; een klasse representeert een object. Een object is "iets". De naam "Berg_Globals" neigt meer naar een handeling (het opbergen van globals). Logischer zou dus zijn "Globals_Opbergplaats" (ofzo). Als je dan gaat extenden klinkt alles automatisch al iets logischer, zoals "Globals_Opbergplaats_GET" (ofzo). Dan weet je dat het een opbergplaats is voor globals maar dan speciaal voor GET. Zelf zou ik mijn opbergplaats niet extenden naar een speciale plaats voor GET en een speciale plaats voor POST; dan haal je juist je flexibiliteit weg denk ik. Daarnaast zijn er in de praktijk waarschijnlijk geen verschillen in het opslaan en afhandelen van GET en POST variabelen.
Als je het principe van een registry nog niet kende dan is het in ieder geval goed dat je zelf bedacht dat dit handig zou zijn. Dus mijn complimenten daarvoor. Technisch kan ik er ook niet veel op aanmerken, het zijn meer de logische keuzes die ik ietsjes anders zou doen. Maar mijn complimenten in het algemeen voor het bedenken van het registry-principe, je OOP-denkpatroon gaat sowieso de juiste richting op.
Als je automatisch alles wil filteren en dergelijke, dan kun je misschien beter een extensie schrijven op een registry-class waarin er automatisch gefilterd wordt.
Als je Zend Framework gebruikt is het het handigst om een kleine plugin in je FrontController te schrijven die automatisch alle request-data ($_REQUEST) filtert met een filter dat je meegeeft in je bootstrap (dat doe je meestal sowieso al). Dan hoef je je sowieso nergens zorgen over te maken.
Even nog ter bevordering van het OOP-denken; een klasse representeert een object. Een object is "iets". De naam "Berg_Globals" neigt meer naar een handeling (het opbergen van globals). Logischer zou dus zijn "Globals_Opbergplaats" (ofzo). Als je dan gaat extenden klinkt alles automatisch al iets logischer, zoals "Globals_Opbergplaats_GET" (ofzo). Dan weet je dat het een opbergplaats is voor globals maar dan speciaal voor GET. Zelf zou ik mijn opbergplaats niet extenden naar een speciale plaats voor GET en een speciale plaats voor POST; dan haal je juist je flexibiliteit weg denk ik. Daarnaast zijn er in de praktijk waarschijnlijk geen verschillen in het opslaan en afhandelen van GET en POST variabelen.
Als je het principe van een registry nog niet kende dan is het in ieder geval goed dat je zelf bedacht dat dit handig zou zijn. Dus mijn complimenten daarvoor. Technisch kan ik er ook niet veel op aanmerken, het zijn meer de logische keuzes die ik ietsjes anders zou doen. Maar mijn complimenten in het algemeen voor het bedenken van het registry-principe, je OOP-denkpatroon gaat sowieso de juiste richting op.
Als je automatisch alles wil filteren en dergelijke, dan kun je misschien beter een extensie schrijven op een registry-class waarin er automatisch gefilterd wordt.
Als je Zend Framework gebruikt is het het handigst om een kleine plugin in je FrontController te schrijven die automatisch alle request-data ($_REQUEST) filtert met een filter dat je meegeeft in je bootstrap (dat doe je meestal sowieso al). Dan hoef je je sowieso nergens zorgen over te maken.
0 -0
-0
Ja, ik ben bekent met het registry...
Ik heb dit ernaast gemaakt, omdat mijn registry:
1) Alleen object bevat, tenzij array ingevoerd (word dan een object, zie mijn RecursiveArrayObject class hier op phphulp)
2) Of een string bevat, wat een callback is naar een class en pas word aangemaakt als het daadwerkelijk ook word opgevraagd.
Ik zal het even uitbreiden, Had wat problemen met mn auth gedeelte, dus was er nog niet aantoegekomen
edit:
hoe pas je dat dan toe op een singleton ?
Ik heb dit ernaast gemaakt, omdat mijn registry:
1) Alleen object bevat, tenzij array ingevoerd (word dan een object, zie mijn RecursiveArrayObject class hier op phphulp)
2) Of een string bevat, wat een callback is naar een class en pas word aangemaakt als het daadwerkelijk ook word opgevraagd.
Ik zal het even uitbreiden, Had wat problemen met mn auth gedeelte, dus was er nog niet aantoegekomen
edit:
Quote:
Waarom maak je ook 2 gelijke classes voor Get en Post? Dan kan je beter 1 abstracte maken lijkt me...
hoe pas je dat dan toe op een singleton ?
0 -0
-0
Quote:
hoe pas je dat dan toe op een singleton ?
De singleton definitie hoef je ook maar een keer te maken, dat is het mooie van die oplossing.
Alleen loop je dan tegen deze regel aan in je instance methode:
Code (php)
1
self::$_get = $_GET;
Ik verbaas me over deze regel omdat die daar eigenlijk niet thuis hoort. Ook vind ik het apart dat het een static variabele is, is dat nodig?
Persoonlijk zou ik die toewijzing aan een niet static member in de constructor doen. Normaal zou je dat ook doen, dus waarom nu niet?
0 -0
-0
Even verwaarlozend dat dit beter binnen het idee van frameworks, OOP en globals == no-go past...
Hoe is dit precies simpeler dan direct $_POST['x'] of eventueel ifset($_POST['x'], 'alternatief') aanroepen? Ik vind de titel een beetje misplaatst ^^,
Hoe is dit precies simpeler dan direct $_POST['x'] of eventueel ifset($_POST['x'], 'alternatief') aanroepen? Ik vind de titel een beetje misplaatst ^^,
0 -0
-0
Daar ben ik het mee eens Jelmer. $_POST['x'] is inderdaad een stuk simpeler om hetzelfde te bereiken.
Een registry vind ik heel handig, maar ook daar zet ik m'n posts en gets niet in, omdat dat overbodig is. Ik filter ze hooguit van te voren, maar ook dan hoeven ze niet in je registry (kan wel). Dus dit principe voor post en get toepassen vind ik ook vrij raar.
Feitelijk is het echt een partyscript (=mijn nieuwe woord) dat meerdere design patterns laat zien en OOP dingen enzo, maar verder geen nut heeft bij deze toepassing.
Een registry vind ik heel handig, maar ook daar zet ik m'n posts en gets niet in, omdat dat overbodig is. Ik filter ze hooguit van te voren, maar ook dan hoeven ze niet in je registry (kan wel). Dus dit principe voor post en get toepassen vind ik ook vrij raar.
Feitelijk is het echt een partyscript (=mijn nieuwe woord) dat meerdere design patterns laat zien en OOP dingen enzo, maar verder geen nut heeft bij deze toepassing.
0 -0
-0
In mijn ogen zijn dit Request variables
GET
POST
FILES
COOKIE
SESSION
SERVER
ik heb daar gewoon een Request class voor.
Deze serialized bijvoorbeeld $_FILES arrays.
filtert eventuele magic_quotes troep
en ik valideer ook bepaalde $_SERVER vars gezien deze ongefiltert van Apache komen...
$_COOKIES en $_SESSIONS hebben een eigen handler.
Door hier een class/ classes voor te gebruiken, kan je dit afdwingen natuurlijk.
Ik vind het voorbeeld in die zin niet helemaal alles.
En in mijn Registry zitten ook alleen maar objecten.
GET
POST
FILES
COOKIE
SESSION
SERVER
ik heb daar gewoon een Request class voor.
Deze serialized bijvoorbeeld $_FILES arrays.
filtert eventuele magic_quotes troep
en ik valideer ook bepaalde $_SERVER vars gezien deze ongefiltert van Apache komen...
$_COOKIES en $_SESSIONS hebben een eigen handler.
Door hier een class/ classes voor te gebruiken, kan je dit afdwingen natuurlijk.
Ik vind het voorbeeld in die zin niet helemaal alles.
En in mijn Registry zitten ook alleen maar objecten.
0 -0
-0
oke, maar nu weet ik nog niet wat je nu precies bedoelt met serializen van $_FILES
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu