URL class
Door Jelmer -, 17 jaar geleden, 7.662x bekeken
Een class om gemakkelijker met urls te werken: samenvoegen, informatie eruit halen, opbouwen en veranderen. Doordat __toString geïmplementeerd is kan je de class bijna overal zonder aanpassingen gebruiken.
Testcase.php bevat een aantal testjes waarin ook de mogelijkheden worden gedemonstreerd.
De checks zijn nog niet helemaal lekker, en zouden eigenlijk volgens de RFC's die urls beschrijven moeten zijn, ware het niet dat die dingen zo lastig te lezen zijn. Ik denk niet dat hij blij is met IPv6 adressen.
Gesponsorde koppelingen
PHP script bestanden
Er zijn 5 reacties op 'Url class'
0 
-0 
-0
Heel mooi, een paar puntjes.
Allereerst zou __toString() een hulpmiddel moeten zijn, geen deel van het model. __toString() zou een parse() methode oid aan moeten roepen en zelf geen functionaliteit bevatten. Denk ik...
Volgens OOP zouden de validators een aparte klasse moeten zijn. Met een factory klasse erbij.
Waartoe dient de factory? De programmeur weet toch wel of het een string of een object is?
Je kan bij het construeren toch vrij makkelijk met een kijken of de URL ok is? Gewoon de geparsede delen door de al gemaakte validators gooien.
Een beetje mee eens?
Allereerst zou __toString() een hulpmiddel moeten zijn, geen deel van het model. __toString() zou een parse() methode oid aan moeten roepen en zelf geen functionaliteit bevatten. Denk ik...
Volgens OOP zouden de validators een aparte klasse moeten zijn. Met een factory klasse erbij.
Waartoe dient de factory? De programmeur weet toch wel of het een string of een object is?
Je kan bij het construeren toch vrij makkelijk met een kijken of de URL ok is? Gewoon de geparsede delen door de al gemaakte validators gooien.
Een beetje mee eens?
0 -0
-0
De reden achter __toString en die factory method zijn dat ik de class zelf als filter gebruik. Maar je hebt gelijk, vanuit OOP gezien is een generate() method netter, en is de factory niet nodig. Ik heb dat even verbeterd.
De validators zou ik niet in aparte classes doen in dit geval omdat de regels voor URL niet veranderen. Een URL is een URL als het aan de definitie van een URL voldoet, en die validators zijn onderdeel van die definitie. Jammer is dan alleen dat ik die validators niet volgens de officiële definitie heb gemaakt. Verbeteringen daarop zijn zeer welkom overigens.
De validators zou ik niet in aparte classes doen in dit geval omdat de regels voor URL niet veranderen. Een URL is een URL als het aan de definitie van een URL voldoet, en die validators zijn onderdeel van die definitie. Jammer is dan alleen dat ik die validators niet volgens de officiële definitie heb gemaakt. Verbeteringen daarop zijn zeer welkom overigens.
0 -0
-0
Je kan toch gewoon een closure gebruiken ipv create_function()?
Ook is merge() van een beetje raar, je kloont het object en wisselt dan de enige data uit. Waarom zou je dan niet gewoon een nieuw object aanmaken?
Ook is merge() van een beetje raar, je kloont het object en wisselt dan de enige data uit. Waarom zou je dan niet gewoon een nieuw object aanmaken?
0 -0
-0
Als mijn hoster nu ook nog update naar PHP 5.3, zou ik inderdaad een closure gebruiken.
In merge gebruik ik clone om zo de constructor en de parse-functie die daarin staat te kunnen vermeiden. In C++ zou je een copy-constructor o.i.d. kunnen gebruiken, maar PHP mist die overloading mogelijkheden. Dus doe ik het zo. Alternatief is dat ik het argument van de constructor optioneel maak, daar is ook wel wat voor te zeggen. Misschien dat ik dat wel doe.
In merge gebruik ik clone om zo de constructor en de parse-functie die daarin staat te kunnen vermeiden. In C++ zou je een copy-constructor o.i.d. kunnen gebruiken, maar PHP mist die overloading mogelijkheden. Dus doe ik het zo. Alternatief is dat ik het argument van de constructor optioneel maak, daar is ook wel wat voor te zeggen. Misschien dat ik dat wel doe.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu