Tijden veranderen
$class->get('iets') vs $class->iets
Ik was even aan het kijken bij het request object van Symfony2 en het volgende valt mij op. Als je bijv. iets van de server wil weten doe je dit:
$request->server->get('iets');
Nu vraag ik me alleen af waarom je "server" direct als property aanspreekt en niet via een get() functie.
Anders gezegd, waarom is het niet dit:
$request->get('server')->get('iets');
(nu gebruik je overal de get() functie)
OF waarom niet dit:
$request->server->iets;
(nu gebruik je nergens de get() functie)
Dit is eigenlijk toch inconsequent?
$request->server->get('iets');
Het enige probleem is dat dit ooit zo is gedaan in Symfony 2.0.0 en helaas zitten grote open source projecten vast aan het zogenaamde backwards compatability. Je kunt niet zomaar zo'n belangrijk ding veranderen, dan forceer je namelijk dat miljoenen developers hun hele code moeten gaan herschrijven. Bundles 'rely' (kan even geen NL vertaling bedenken) op deze functionaliteit en daarom is het gewoon simpelweg nooit aangepast.
$request->get('server')->get('iets');
Is dit de juiste methode?
Toevoeging op 05/02/2013 20:17:43:
Is het trouwens het handigst om inderdaad dit te doen:
$request->get('server')->get('iets');
Of is dit beter
$request->getServer()->get('iets');
$request->getPost()->get('iets');
enz.
Of maakt dat niks uit?
Maar ik zit nu wel even te denken... van de ene kant is dit vrij omslachtig:
$request->getServer()->get('iets');
$request->getPost()->get('iets');
en dan bedoel ik dus getServer() en getPost()... want als je die lijn doortrekt (een eigen get functie voor iedere property) dan zou je bijvoorbeeld voor alle variabelen in de $_SERVER array een eigen functie moeten maken. getHTTP_HOST() getUri() enz. enz. Dat is eigenlijk niet te doen. De keuze zou dan zijn om een algemene get() functie te gebruiken die op basis van de key iets ophaalt. Als je het zo redeneert, dan zou je dus niet getServer() en getPost() moeten gebruiken, want dat is dan niet consistent.
Maaaaar... als je de bovengenoemde lijn dan weer doortrekt dan zou je bij een User class dus ook geen getUsername en getAge() en getWeetikwat() moeten gebruiken, maar altijd een algemene get() functie, dus get('username'). Hoe kijk jij daar tegenaan. Ben je het hier mee eens?
Gewijzigd op 05/02/2013 20:28:45 door Ozzie PHP
- Raoul - op 05/02/2013 20:38:56:
get() zou ik niet gebruiken aangezien je dit kan verwarren met iets ophalen uit de DI container.
Die logica zie ik even niet. Omdat je een functie get() hebt in je DI container, zou je die nergens anders mogen gebruiken??? Dat lijkt me vreemd.
Als je consistent wil zijn (en dat wil je lijkt me) dan zou je OF overal get('key') moeten gebruiken OF overal getKey(). Toch?
Gewijzigd op 05/02/2013 20:44:05 door Ozzie PHP
- Gebruik specifieke getters (getSession, getQuery, getName, ect.) als je de data die je 'get' vast staat.
- Gebruik de algemene get method als de data dynamisch is. Je weet helemaal niet welke session data je allemaal hebt, je weet helemaal niet welke services je allemaal hebt, je weet helemaal niet welke header informatie je allemaal hebt.
Het zou dan dus worden:
Code (php)
1
2
3
2
3
<?php
$request->getSession()->get('foo');
?>
$request->getSession()->get('foo');
?>
Gewijzigd op 05/02/2013 22:16:19 door Wouter J
Maar bij het request, als je de server ophaalt, dan zou jij dus dit doen:
$request->getServer()->get('URI');
Begrijp ik het zo goed?
Offtopic:
Is session eigenlijk een onderdeel van het request? (omdat je niet altijd een sessie hebt?)
Quote:
Is session eigenlijk een onderdeel van het request? (omdat je niet altijd een sessie hebt?)
Ja. Onder de Request object zit alle - mogelijke - informatie die de browser/bezoeker naar jou toestuurt. In de Response object zit alle informatie die jij terugstuurt naar de browser.
asp.NET(C#)
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
class User{
private
decimal fBalance;
public
decimal CurrentBalance{
get {return this.fBalance;}
}
private
decimal fBalance;
public
decimal CurrentBalance{
get {return this.fBalance;}
}
Nog 1 laatste vraag... we hadden het een tijdje terug over Session(s). Weet je nog, dat misverstand? In mijn ogen was de Session de complete $_SESSION array en ni jouw ogen was een session 1 key/value paar uit de $_SESSION array.
Ik ben nu bezig met het request object. Ik wil dan (bijv.) de $_GET array als property toevoegen aan de request class door middel van zo'n propertybag constructie. Wat ik me nu alleen afvraag... stop je de complete $_GET array in 1 propertybag? Ik neem eigenlijk aan van wel, en dat je dan in die propertybag 1 property (een array) hebt, waarin je alle waardes uit de $_GET array stopt.
Maar omdat het met die Session zo was dat je iedere waarde in een Session class moet stoppen, weet ik niet of het bovenstaande wel klopt (of misschien heb ik het verhaal van de sessie verkeerd begrepen).
Is het de bedoeling dat ik alle waardes uit de $_GET array in 1 propertybag class stop?
Ger, of in dat o zo mooie Ruby: (waar properties alleen private kunnen zijn en ze doormiddel van getters/setters tot 'soort van publiek' omgetoverd kunnen worden)
Code (php)
1
2
3
4
5
2
3
4
5
class User
@fBalance
attr_reader :CurrentBalance
end
@fBalance
attr_reader :CurrentBalance
end
Oké... om de avond goed af te sluiten dan nog even deze...
De $_GET waardes stop ik in 1 property bag... maar wat doe ik dan met de $_SESSION waardes?
(We hadden laatst zo'n disussie over een session_manager en een Session class waar telkens 1 key/value paar in wordt gestopt. Dat is dan toch afwijkend van zo'n propertybag? Waar zit het verschil?)
Gewijzigd op 05/02/2013 23:00:58 door Ozzie PHP
Maar waarom geef je de waardes uit de $_SESSION array een eigen class, terwijl je dat met de $_COOKIE, $_GET en $_POST waardes niet doet. Wat is het verschil?
POST en GET parameters hebben deze eigenschap niet. In feite zijn de PropertyBags van POST en GET gewoon alleen read_only, je kan ze toch niet meer aanpassen. SESSION's maken daarin tegen deel uit van de Request klasse, de informatie die je van de bezoeker krijgt, maar zijn ook een mogelijkheid tot het opslaan van data. Een dubbele functie dus.
Echter, de waardes van de POST en GET parameters kan ik ook overschrijven. Ik zou dit kunnen voorkomen door ná het instellen van de parameters een class property 'write' op false te zetten of iets dergelijks, maar qua performance lijkt me dat niet slim. Je zou dan telkens als de set functie wordt aangeroepen moeten controleren of de property 'write' op true staat. Als je dan 100 parameters wil inladen, voert ie 100x onnodig die controle uit. Of is er een andere manier om 'read-only' in te stellen?
Ik snap het verhaal van de Sessie class nu wel. Vraag ik me alleen nog af... in welk opzicht (welke functies) verschilt de SessionPropertyBag van de normale propertybag?
(PS, het ding heet toch ParameterBag ipv PropertyBag?)
Quote:
Of is er een andere manier om 'read-only' in te stellen?
Dit minime verschil in performance moet je je echt niet druk over maken. Je zou, zoals ik je pas had uitgelegd, de ParameterBag kunnen laten bevriezen, zodat je hem alleen nog maar kunt uitlezen.
Quote:
in welk opzicht (welke functies) verschilt de SessionPropertyBag van de normale propertybag?
Dat een normale ParameterBag 2 argumenten heeft bij de set functie: set(string $key, mixed $value) en dat een SessionParameterBag 1 argument heeft bij de set functie: set(Session $session)
Quote:
(PS, het ding heet toch ParameterBag ipv PropertyBag?)
Klopt, foutje van mij.
"Dit minime verschil in performance moet je je echt niet druk over maken. Je zou, zoals ik je pas had uitgelegd, de ParameterBag kunnen laten bevriezen, zodat je hem alleen nog maar kunt uitlezen."
Klopt dat zei je, maar ik heb geen idee hoe je zoiets bewerkstelligt. Hoe bevries je zo'n ParameterBag?