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);
Ja maar zodra de argumenten niet vaststaan kunnen we ze niet meegeven aan de contructor, right? En om iets een service te laten zijn, hadden we besloten dat de argumenten altijd hetzelfde moeten zijn. Ik geef de global data dus niet mee aan de constructor, want die is niet altijd hetzelfde. Ik hou me dus nog steeds aan de norm van een service.... Jij daarentegen :) Jij gooit variabele data in de constructor, waardoor jouw request dus eigenlijk geen service meer is, en vervolgens voeg je het request object dan maar toe aan de services, terwijl het hele request-object nergens in je services-configuratie is terug te vinden. En dan is mijn oplossing niet mooi? ;-)))))
Oke, hierbij zien we dus een verschil in mooi zijn. De een houdt meer vast aan OO, terwijl de ander meer aan de container denkt.

Nu ik er zo over nadenk valt er voor beide wel wat te zeggen. En dan heb ik precies mijn doel bereikt, er zit een gedachte achter de code. Maar of die gedachte goed is... :P

[semi-offtopic]
Ik heb me zelf ook nog nooit zoveel bemoeit met de request service in Symfony. Er zijn al heel wat discussies over geweest. En heel wat features, scopes, synchronized services, abstract services, zijn er in de DI component gekomen omdat Fabian (author van Symfony) het perse via de constructor wil doen en support wil bieden voor subrequests.
[/semi-offtopic]
>> Nu ik er zo over nadenk valt er voor beide wel wat te zeggen.

Hehe, dat werd tijd ;-)))

Soms is het handiger om met je boerenverstnd iets op te lossen, dan om vast te houden aan iets zonder dat daar echt een goede reden voor is. In dit geval denk ik dat "mijn" manier wat efficiënter is, en dat de request ook echt een service is. Mijn motto is, als iets op een simpele manier kan, dan moet je het ook op een simpele manier doen (tenzij de meer ingewikkelde manier aanzienlijke voordelen biedt, maar dat is in deze situatie niet het geval).

Anyhow, we hebben weer even lekker gebrainstormd :)

Reageren