sessie en cookie
Ik zat me ineens wat af te vragen. Als je een framework hebt, dan haal je eerst het request binnen. Onderdeel van dat request zijn onder andere de sessie-data en cookie-data.
Nu zat ik me dus af te vragen... stel ik wil iets in een cookie of sessie wegschrijven, dan zou ik zoiets kunnen doen: $this->container->get('request')->getSession()->save('foo', $foo);
Maar toen bedacht ik me dat het eigenlijk heel vreemd is om via het request (datgene wat binnenkomt) iets op te slaan in een cookie of sessie. Want eigenlijk zou het request alleen de data van de cliënt moeten vasthouden, en zou je daar verder niks mee moeten kunnen doen. Toch? Anders gezegd, het lijkt me vreemd om data op te slaan in het request dat van de cliënt afkomstig is.
Vraag 1) Is mijn bovenstaande gedachte correct?
Oké. Stel nu dat we dan de sessie gegevens vanuit het request doorsturen naar een session handler. Dan kunnen we via die session handler iets gaan opslaan in de sessie. Dan sla ik de informatie dus niet meer op via het request. Dat lijkt me een stuk beter!
Vraag 2) Is bovenstaande redenatie correct?
Vraag 3) De laatste vraag. Stel dat we een session handler hebben, is die dan een onderdeel van de response? Ik vraag me dit af, omdat je door informatie in sessie (of cookie) te schrijven, je in feite iets wegschrijft bedoeld voor de cliënt. Je geeft een response richting de cliënt zou ik denken. Als je dan iets wil opslaan in de sessie, dan zou je zoiets krijgen:
$container->get('response')->getSession()->save('foo', $foo);
Klopt deze gedachtengang enigszins? Is een session handler inderdaad onderdeel van de response, of staat een session handler op zichzelf? Of is het misschien wel onderdeel van een storage service, dus zoiets: $container->get('storage')->getSession()->save('foo', $foo);
Gewijzigd op 18/10/2013 20:31:26 door Ozzie PHP
Sessies zijn ook niet alleen $_SESSIONS dingen. Sessies zijn kleine waardes die je tijdelijk opslaat. Je kan bijv. ook sessies in je database stoppen.
Dus het opslaan van sessies wordt dan:
Code (php)
1
2
3
2
3
<?php
$container->get('session.default_handler')->save(...);
?>
$container->get('session.default_handler')->save(...);
?>
Even voor de zekerheid, je begrijpt dat de bovenstaande regel niet echt in je code gebruikt moet worden, maar dat je de session.default_handler service injecteert in je class en dan $this->sessionHandler->save(...) gebruikt?
Je laatste opmerking was overigens ook wel nuttig. Als ik het zo lees dan is het inderdaad heel logisch wat jij zegt, maar in gedachten dacht ik dus inderdaad om in een class gewoon zoiets te doen:
$container->get('session.default_handler')->save(...);
Maar inderdaad, in de class injecteren dus! Thanks voor de reminder.
Ik heb wel nog een andere vraag die hier een beetje mee samenhangt. Misschien kun je me daar nog bij helpen.
Ik weet niet zo goed welke services "bij elkaar horen". Hoe leg ik dat uit... Bijvoorbeeld... als ik cookie-data wil uitlezen, of post- of get-data, dan is dat mooi om dat via een "request"-service te doen, dus zoiets als:
$container->get('request')->getCookie()->get('foo');
De request service (correct me if I'm wrong) zou je dan weer kunnen injecteren met de cookie, post, get services enz.
Als je dat in een "boomstructuur" giet dan krijg je dus (grofweg) eigenlijk zoiets:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
Services:
-request
- cookie
- get
- post
- enz.
-request
- cookie
- get
- post
- enz.
Nu vraag ik me af of er nog meer services zijn die "onderdeel" zijn van een andere service. M'n vraag klinkt misschien een beetje stom, maar ik hoop dat je begrijpt wat ik bedoel. Eerder vandaag noemde jij bijv. het voorbeeld van de User die onder de SecurityContext valt.
Concreet: ik ben nu bezig met een paths service (ja, ik weet dat jij het via parameters doet, maar ik doe het via een service). En in het verlengde daarvan wil ik ook een url service maken. Wat ik uiteindelijk wil kunnen doen is dit:
$container->get('paths')->get('library');
of dit:
$container->get('urls')->get('index');
Nu is mijn vraag... kan ik paths en urls "zomaar" out of the blue aanroepen? Ja tuurlijk kan dat, want dat doe ik hierboven... maar is dit "mooi"? Of moet ik Paths en Urls onder een andere service hangen? En zo ja, onder welke? Wat zou dan een mooie "kapstok" service zijn? Ik zat zelf bijv. te denken aan iets als "system". Dan krijg je dus zoiets:
$container->get('system')->getPaths()->get('library');
Alleen... system is weer zo globaal, dat je daar dan eigenlijk alles wel weer onder kunt hangen. Wat is jouw visie hierop? Paths en Urls gewoon als losse service instellen, of onderbrengen onder een andere service... maar in dat geval, wat zou dan een mooie naam zijn?
Wrong! Request is een hele vreemde service en het is een service die de makers van het symfony framework nog steeds bezig houdt. Wat het vreemde is aan deze service is dat hij niet wordt aangemaakt door de service container, maar hij wordt onthefly in de service container ingesteld.
> Wat is jouw visie hierop?
- paths, zoals al eerder vertelt, ik zou alle paths in parameters opslaan.
- routes, worden aangemaakt door de router
Ah oke... maar cookie, get, post enz. vallen wel onder de request service. Je benadert ze niet rechtstreeks maar via de request service.
Wat betreft de paths, ik weet dat jij ze als parameters zou opslaan, maar ik wil ze dus in een service stoppen. Persoonlijke voorkeur. Maar mijn vraag is dus... mag je zo'n service gewoon "losstaand" instellen, of moet je het onder een "kapstok" hangen. Ander voorbeeld. Stel je hebt een e-mailer service of een pdf service. Stel je die "op zichzelf" in, of hang je ze onder een kapstok...
Op zichzelf:
Code (php)
1
2
3
4
2
3
4
<?php
$container->get('e-mailer')->send();
$container->get('pdf')->create('foo_pdf', $foo_data);
?>
$container->get('e-mailer')->send();
$container->get('pdf')->create('foo_pdf', $foo_data);
?>
of onder een "kapstok"...
Code (php)
1
2
3
4
2
3
4
<?php
$container->get('communication')->getEmailer()->send();
$container->get('generators')->getPdf()->create('foo_pdf', $foo_data);
?>
$container->get('communication')->getEmailer()->send();
$container->get('generators')->getPdf()->create('foo_pdf', $foo_data);
?>
Moet je dus iedere service onder een soort overkoepelende service hangen, of juist niet... en moet iedere service "op zichzelf" staan?
("- routes, worden aangemaakt door de router". Uhm ja, maar routes zijn geen urls toch? Of combineer jij de routes en urls?)
Iemand nog een idee?
Ja, maar die kunnen niet door de service container worden toegevoegd aan de request service. Dus wanneer je hem aanmaakt moet je iets als $container->addService('request', $request); doen.
>> ("- routes, worden aangemaakt door de router". Uhm ja, maar routes zijn geen urls toch? Of combineer jij de routes en urls?)
Dan vraag ik me af wat je met urls bedoelt
Duidelijk!
>> Dan vraag ik me af wat je met urls bedoelt
Stel je wil een plaatje tonen en alle plaatjes staan in de map "images", dan wil ik in mijn code dit kunnen doen:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$image_url = $container->get('urls')->get('image');
// En als ik in dan in een view een plaatje nodig heb...
echo $image_url . 'mijnplaatje.jpg';
?>
$image_url = $container->get('urls')->get('image');
// En als ik in dan in een view een plaatje nodig heb...
echo $image_url . 'mijnplaatje.jpg';
?>
En dat zou dan weer moeten resulteren in http://www.mijnsite.nl/images/mijnplaatje.jpg. En hetzelfde kun je doen voor css urls, javascript urls enz.
Toevoeging op 20/10/2013 16:20:54:
Tussen 2 haakjes...
>> Ja, maar die kunnen niet door de service container worden toegevoegd aan de request service. Dus wanneer je hem aanmaakt moet je iets als $container->addService('request', $request); doen.
Je zou ook zoiets kunnen doen toch?
Code (php)
1
2
3
4
2
3
4
<?php
$request = $container->get('request');
$request->addGlobals($globals);
?>
$request = $container->get('request');
$request->addGlobals($globals);
?>
Nee, want bij een nieuw request wil je een nieuwe instance, niet dezelfde instance met andere waardes.
Ik snap ook niet wat jij bedoelt met "want bij een nieuw request wil je een nieuwe instance". Overal in je code waar je het request nodig heb, wil je toch hetzelfde request terugkrijgen?
Klopt, maar resulteert in meerdere requests bv voor css, js, images etc.
Ger van Steenderen op 20/10/2013 18:01:59:
Per page request heb je dus maar 1 request.
Klopt, maar resulteert in meerdere requests bv voor css, js, images etc.
Klopt, maar resulteert in meerdere requests bv voor css, js, images etc.
Ja, maar daar heb je toch geen extra request services voor nodig :-s
Of zie ik iets over het hoofd nu?
Maar van het "hoofdrequest" wil je toch altijd dezelde instantie terugkrijgen? Maak jij dan onderscheid in je services tussen een hoofdrequest en een subrequest?
Maar uitgaande dat ik maar 1 request gebruik, dan kan ik die toch instellen als service, en daar dan de data in stoppen... in plaats van eerst een class maken, vullen met data en die aan de services meegeven?
Hoe wil jij $_POST en $_GET waardes invullen via de container?
De request-service is dus in 1e instantie niet gevuld. ALs onderdeel van je initialisatie haal je dan de lege request-service op en die vul je, bijv. zo:
$container->get('request')->addGlobals($globals);
Waarbij de globale data dus in de $globals array zit.