Ola mensen,

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);
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.

Ja, maar daar heb je toch geen extra request services voor nodig :-s
Of zie ik iets over het hoofd nu?

We hebben hier een tijd geleden ook al een discussie over gehad, maar je hebt ook subrequests
Ja, ik herinner me ook zoiets :)

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?
>> 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?
Die komen van buitenaf...

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.

En dat vind je mooie OO?
Euh.. wat bedoel je daarmee? Wat is daar minder mooi aan dan jouw oplossing? Verklaar je nader, want ik zie niet wat je bedoelt te zeggen.
Gewoon, ik wou dat jij ging nadenken of je niet veel te veel met 'hoe kan ik het in de code het makkelijkst toepassen' (de spaghetti methode) en niet met 'hoe zou het in OOP het mooiste zijn' (de OO denk methode) bezig was.
Ja, maar wilde je nu dat ik ging nadenken... of vond jij het zelf niet mooi? Mij lijkt het namelijk wel mooi om het zo te doen.
:) Leuk, ik vind dit niet mooi. Waarom? Bedenk eens wanneer we ook al weer hadden besloten argumenten in de constructor te plaatsen en wanneer deze via een setter/adder/whatever ingesteld zouden worden. Ga vervolgens eens naar jouw voorbeeldje kijken waarbij je de container even weg denkt en bedenk je wat je dan 'oo-er' vind.

Reageren