Makkelijk gebruik Globals

Door Iltar van der berg, 20 jaar geleden, 4.059x 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)
PHP script in nieuw venster Selecteer het PHP script
1
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'] : '');
?>


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

  1. makkelijk-gebruik-globals

 

Er zijn 14 reacties op 'Makkelijk gebruik globals'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Terence Hersbach
Terence Hersbach
20 jaar geleden
 
0 +1 -0 -1
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
    /**
     * prevent direct access
     *
     */

    private function __construct()
    {
        
    }

    
    /**
     * prevent cloning
     *
     */

    private function __clone()
    {
        
    }

?>

Beetje zinloos.. niet?
Iltar van der berg
iltar van der berg
20 jaar geleden
 
0 +1 -0 -1
Tuurlijk niet... Kijk bij de comments, en zie wat private doet tov public.
Lode
Lode
20 jaar geleden
 
0 +1 -0 -1
Eigenlijk moet je ze nog final maken ook...
Anders zou je ze kunnen omzeilen als je de class extend...

het is trouwens gewoon:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
if(!self::$_instance instanceof self){} //geen extra () nodig...
?>


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....
Iltar van der berg
iltar van der berg
20 jaar geleden
 
0 +1 -0 -1
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.
Bo az
Bo az
20 jaar geleden
 
0 +1 -0 -1
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:
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.
Lode
Lode
20 jaar geleden
 
0 +1 -0 -1
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 ?
Iltar van der berg
iltar van der berg
20 jaar geleden
 
0 +1 -0 -1
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
PHP erik
PHP erik
20 jaar geleden
 
0 +1 -0 -1
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.
Iltar van der berg
iltar van der berg
20 jaar geleden
 
0 +1 -0 -1
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:
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 ?
Bo az
Bo az
20 jaar geleden
 
0 +1 -0 -1
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)
PHP script in nieuw venster Selecteer het PHP script
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?
Jelmer -
Jelmer -
20 jaar geleden
 
0 +1 -0 -1
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 ^^,
PHP erik
PHP erik
20 jaar geleden
 
0 +1 -0 -1
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.
Lode
Lode
20 jaar geleden
 
0 +1 -0 -1
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.
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Iltar van der berg
iltar van der berg
20 jaar geleden
 
0 +1 -0 -1
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.

Inhoudsopgave

  1. makkelijk-gebruik-globals

Labels

  • Geen tags toegevoegd.

Navigatie

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.