[oop] sessie
Ik ben benieuwd hoe de meesten van jullie omgaan met gegevens uit de $_SESSION array.
Om deze gegevens te gebruiken, stop je ze vaak in een session(handler) class. Nu kun je hier op 2 manieren mee omgaan. Ik vraag me af hoe de meesten van jullie dat doen.
Manier 1:
Je hebt een session class en daar stop je de $_SESSION data in, bijv. $session = new Session($_SESSION). In de constructor zeg je dan $this->session_data = $session_data. Op het moment dat je iets uit de sessie wil halen doe je $session->get('foo'). Je spreekt dan dus de class property (de $session_data array) aan.
Manier 2:
Je maakt van iedere element in de $_SESSION array een apart object. Al deze objecten laad je vervolgens in in een session handler. Als je nu data wil ophalen, dan moet je dus eerst een apart session object ophalen $foo = $session_handler->get('foo'). Nu hebben we dus een object te pakken. Vervolgens halen we daar de value uit $foo->getValue(). Of, gewoon in 1x $foo = $session_handler->get('foo')->getValue().
Welke manier gebruiken jullie, en waarom?
Gewijzigd op 27/02/2014 00:20:50 door Ozzie PHP
http://www.phphulp.nl/php/forum/topic/session-manager/89332/
http://www.phphulp.nl/php/forum/topic/sessie-en-cookie/92634/
Of je nu $session->get('iets') doet of je doet $_SESSION['iets']. Het maakt werkelijk geen enkel verschil.
Maar dat is wel jouw "manier 1" die je beschrijft. Zelfde principe geldt ook voor jouw "Manier 2". Waarom denk je dat dit "goed" zou zijn?
Het is overigens wel goed om een Session class te maken, maar ik vraag me af of je uberhaupt wel het idee er achter weet. Of dat je maar ergens iets hebt gehoord/gelezen over zoiets en het maar klakkeloos aan neemt en wil gaan implementeren.
Gewijzigd op 27/02/2014 09:06:51 door D Vivendi
>> Het is overigens wel goed om een Session class te maken...
Nou, ik zou zeggen, leg uit... want je lijkt jezelf nu tegen te spreken.
In dit geval is $_SESSION inderdaad een global. En globlas wil je vaak mijden. Maar vergeet niet dat $_SESSION in zekere zin een ander soort global is. Het hoort namelijk bij PHP. Dus iedereen die PHP draait heeft altijd $_SESSION tot zijn beschikking. Dit hoeft dus niet perse slecht te zijn als jij alleen maar $_SESSIONs uitleest in je controller en daar voldoende aan hebt. Ik zou dan ook zeker geen moeite steken in het maken van een "wrapper" class die eigenlijk precies het zelfde kan/doet.
De rede dat je een Session class maakt is omdat je niet alleen sessions wilt ondersteunen zoals je die kent van $_SESSION. Maar het kan bijvoorbeeld ook zijn dat je juist net iets anders wil. Dat je je sessions bijvoorbeeld wilt opslaan in een database, of in een file, of als cookie, of in iets als Redis of alleen in memory. Noem maar op.
Het enige wat jij als gebruiker van die Session class wilt doen is aangeven in een config bestand wat voor soort Session je wilt gebruiken en daarvoor nog de nodige attributen bij configureren.
Session opslaan in een file, geef dan een besstandslocatie en naam mee. Wordt het Redis, dan een database naam etc.
Daar bij komt kijken dat de wat betere Session classes ook vaak dingen doen tegen session hijacking. Dit en nog veel andere dingen kan je dus meenemen in een Session class en dan heb je er ook echt iets aan.
Kijk juist ook vooral naar al bestaande classes in dit soort gevallen. Die kunnen je op ideeen brengen van wat je er allemaal mee zou kunnen doen.
En als jij het hebt over een session class voor de global $_SESSION, werk jij dan met 1 class waarmee je als het ware de $_SESSION array kan bewerken? Of maak jij van ieder session element 1 class, en gebruik je een session manager om die afzonderlijke classes te "bedienen"?
Dat is hoe ik het ook ongeveer heb. Je kan natuurlijk altijd hier en daar een beetje je eigen draai er aan geven.
Probeer in elk geval conflicten te voorkomen. Omdat $_SESSION wordt gedeeld door alle objecten én door meerdere requests (de factor tijd), kan er bijvoorbeeld met een $_SESSION['email'] van alles en nog wat mis gaan.
Wat ik bedoel is, stel in de S_SESSION array zit een key 'foo' met als waarde 'bar'. Jullie zouden hier dan een object van maken. Nu is mijn vraag of jullie dan dat hele object opslaan in de $_SESSION array.
>> dat $_SESSION wordt gedeeld door alle objecten én door meerdere requests (de factor tijd), kan er bijvoorbeeld met een $_SESSION['email'] van alles en nog wat mis gaan.
Kun je een voorbeeld geven?
Wat me trouwens ineens te binnen schiet... maken externe libraries (en dan bedoel ik niet frameworks overigens) weleens gebruik van session data, of van superglobals ($_GET, $_POST, $_FILES, $_SERVER)?
Je kunt een sessie dus beter modelleren als een gedeelde cache, want dat is het in wezen ook. Dat beantwoordt meteen je tweede vraag:
>> Nu is mijn vraag of jullie dan dat hele object opslaan in de $_SESSION array.
Ja en nee. Dat hangt er puur vanaf of een objectcache ergens in je ontwerp structurele voordelen oplevert.
Maar dit is toch niet anders dan voorheen?
Ik bedoelde met mijn vraag eigenlijk iets anders, en misschien heb ik het niet duidelijk uitgelegd. Als ik iets wilde opslaan in de $_SESSION array dan deed ik eigenlijk dit $_SESSION['name'] = 'Ozzie'. Als ik jullie goed begrijp, dan maken jullie van iedere element een class. Dus dan zou je bijv. dit krijgen $session = new Session('name', 'Ozzie'). En deze session geef je dan door aan de session manager. Vervolgens slaat de session manager de session op. Maar hoe? Wat gebeurt er onderwater? Dit $_SESSION['name'] = $session (het complete object wordt opgeslagen) of dit $_SESSION['name'] = 'Ozzie' (de value wordt opgeslagen)?
Weet je het antwoord op deze vraag ook?
"Wat me trouwens ineens te binnen schiet... maken externe libraries (en dan bedoel ik niet frameworks overigens) weleens gebruik van session data, of van superglobals ($_GET, $_POST, $_FILES, $_SERVER)?"
Uiteindelijk kan er immers maar één $_SESSION['name'] worden opgeslagen. Dan moet je dus voorkomen dat verschillende applicaties een $_SESSION['name'] gebruiken.
Vergelijk het met een bestandsconflict. Je wilt niet dat meerdere applicaties een index.php in een directory kunnen opslaan, om maar eens een voorbeeld te verzinnen. Zo werkt dat met een cache ook.
En ja, libraries maken vaak gebruik van superglobal arrays. Je kunt immers geen URL routen zonder een HTTP GET en geen formulier verwerken zonder een HTTP POST.
Jawel, dat begrijp ik. Maar ik begrijp nog niet welk punt je probeert te maken. Wat heeft die session manager hier mee te maken? En ik probeer m'n vraag nog een keer te stellen. Wat wordt er nu in de $_SESSION array opgeslagen. Verwijst iedere key naar zo'n Session object?
Code (php)
1
2
3
4
2
3
4
$_SESSION:
'name' => Session object
'forum' => Session object
'status' => Session object
'name' => Session object
'forum' => Session object
'status' => Session object
>> En ja, libraries maken vaak gebruik van superglobal arrays. Je kunt immers geen URL routen zonder een HTTP GET en geen formulier verwerken zonder een HTTP POST.
Hmmm, oké. Ik breng de globals van buitenaf in in het request object, dus ik dacht dan kan ik de globals (muv cookie en sessie) eigenlijk net zo goed unsetten. Dan nemen ze geen ruimte in beslag. Maar het kan dus zijn dat een externe library ze nodig heeft. Daar had ik eigenlijk niet aan gedacht... maar bijv. een PDF library die heeft toch geen globals nodig?
Gewijzigd op 27/02/2014 17:32:54 door Ozzie PHP
Als verschillende objecten of applicaties een 'name' willen opslaan in $_SESSION, zal de session manager dat in goede banen moeten leiden. Dat betekent dus dat de session manager dat niet zomaar in een $_SESSION['name'] stopt, maar een mechanisme aan boord heeft om de 'name' voor X en de 'name' voor Y uit elkaar te houden.
Maar is er iemand die mijn vraag begrijpt wat betreft de session objecten? Er wordt dus gesteld dat we voor ieder element een afzonderlijke Session class gebruiken. Worden die objecten zelf opgeslagen in de S_SESSION array? Snapt iemand mijn vraag?