Door
Ozzie PHP
op 27-02-2014 00:18
gewijzigd op 27-02-2014 00:20
3.277 views
Ola,
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().
Ik heb voor ieder 'element' een andere class. Want ieder wilt ook zijn eigen ding doen. Daar achter zit weer een soort Manager die de juiste class aanspreekt. Het gaat nog wel wat verder dan dat. Ik heb eigenlijk het meeste ook afgekeken van: https://github.com/fuelphp/session
Dat is hoe ik het ook ongeveer heb. Je kan natuurlijk altijd hier en daar een beetje je eigen draai er aan geven.
Even voor mijn beeldvorming... we hebben dus een $_SESSION array. Sla jij hierin dan ook daadwerkelijk objecten op? Of blijven het wel gewoon key => value paren?
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.
>> Key/value-paren gebruik je ook bij objecten ;-)
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)?
Dat is precies het type conflict dat ik bedoel. Als twee objecten beide een $_SESSION['email'] kennen, treden er zonder session manager conflicten op. Of die $_SESSION['email'] nu een e-mailadres is, de tekst voor een nieuw e-mailbericht of een compleet e-mailobject doet dan niet eens ter zake: je hebt hoe dan ook een probleem.
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.
>> Dat is precies het type conflict dat ik bedoel. Als twee objecten beide een $_SESSION['email'] kennen, treden er zonder session manager conflicten op. Of die $_SESSION['email'] nu een e-mailadres is, de tekst voor een nieuw e-mailbericht of een compleet e-mailobject doet dan niet eens ter zake: je hebt hoe dan ook een probleem.
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)?"
Keer het eens om en kijk vanuit de sessie: wat zou een $_SESSION['name'] dan betekenen?
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.
>> Uiteindelijk kan er immers maar één $_SESSION['name'] worden opgeslagen. Dan moet je dus voorkomen dat verschillende applicaties een $_SESSION['name'] gebruiken.
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?
>> 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?
>> Wat heeft die session manager hier mee te maken?
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.
Dat zou kunnen. Dan moet je dus bijv. per library de key prefixen ofzo? Dus niet 'name' maar 'ozzie_name'. Is dat wat je bedoelt?
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?
