Tijden veranderen
[oo] Correcte benaming namespace?
Code (php)
De code hierboven leeft in /src/controller/HelloController.php.
Nu mijn vraag: mag ik als namespace zomaar Controller gebruiken? Moet er geen projectnaam bij ofzo? Want ik heb de projectnaam van m'n framework al er bij gezet?
En als ik dan toch een projectnaam erbij zet, moet het dan /src/ProjectNaam/controller/HelloController.php worden ofzo?
Alvast bedankt
Raoul
Gewijzigd op 05/12/2012 11:48:14 door - Raoul -
Vaak staan het framework en de 3th-party libraries in de vendor/ of library/ map en leeft de project code in de normale map.
Ik raad aan namespaces op te bouwen volgens de PSR-0 standaard, wat inhoudt dat je <vendor-name>\<namespace>\<namespace...>\<class> gebruikt. De vendor name is de naam van je applicatie. Stel je maakt een RaoulPHP framework en die heeft een Mvc\Application class dan wordt de namespace dus RaoulPHP\Mvc\Application. Deze leeft dan in: vendor/RaoulPHP/Mvc/Application.php
Voor de 3th party geldt hetzelfde. Ik raad je aan composer te gebruiken, die zorgt dat alles goed komt en al je dependencies (=3th-party libraries) in de vendor library staan en dat de namespaces allemaal kloppen.
De project specifieke code is natuurlijk een ander verhaal. Die moet je ook prefixen, in ZF1 gebeurd dit met de Application preffix als ik het goed heb. Je stelt dan in de autoloader in dat de Application namespace gewoon in de project root leeft.
Je krijgt dan klassen als Application\Controller\HelloController welke dan in Controller/HelloController.php leeft.
Maar wat je tegenwoordig steeds meer ziet (in ZF2 en Symfony sowieso) is het gebruik van Bundles/Modules. Je groepeert code op basis van hun functie. Je hebt bijv. bundle voor alles met de user (de UserBundle) en een bundle voor een admin interface (de AdminBundle) en nog eentje voor alle blog dingen (de BlogBundle), ect. Deze zet je allemaal in een map en geef je dus hun eigen vendor mee. Je krijgt dan dus een BlogBundle\Controller\PostController klasse die bijv. in src/BlogBundle/Controller/PostController.php leeft.
Symfony gaat nog een stap verder en gebruikt vendors. Je hebt geen BlogBundle maar bijv. een WjBlogbundle. Hierdoor heb je de mogelijk 2 verschillende bundles te gebruiken. Je krijgt dan een Wj\BlogBundle\Controller\PostController klasse die in src/Wj/BlogBundle/Controller/PostController.php leeft.
Zo ziet alles er nu uit:
(Framework is trouwens het framework, heb nog niet echt een naam).
Dat van Composer is trouwens een goeie tip, ben alleen beetje bang of Spyc wel zo'n repo heeft (of hoe dat ook heet) anders kan ik altijd nog steeds yaml loader van Symfony gebruiken.
Dat van bundles en modules lijkt me trouwens heel interessant en zeker overzichtelijk! Als ik dan bijvoorbeeld aan routing doe, en ik wil een controller mappen aan een route, is dit dan een correcte manier van doen?
(voorbeeld yml code van hoe ik het wil doen)
Code (php)
1
2
3
4
2
3
4
blogpost:
pattern: /blog/post/{id}
method: [ GET, POST ]
controller: Sitenaam:BlogModule:Hello:index
pattern: /blog/post/{id}
method: [ GET, POST ]
controller: Sitenaam:BlogModule:Hello:index
Quote:
Dat van Composer is trouwens een goeie tip, ben alleen beetje bang of Spyc wel zo'n repo heeft (of hoe dat ook heet) anders kan ik altijd nog steeds yaml loader van Symfony gebruiken.
Mocht je wat meer informatie willen over composer kun je eventueel mijn blogpost erover lezen: http://wouterj.nl/php/werken-met-composer/509/
Quote:
Dat van bundles en modules lijkt me trouwens heel interessant en zeker overzichtelijk! Als ik dan bijvoorbeeld aan routing doe, en ik wil een controller mappen aan een route, is dit dan een correcte manier van doen?
Ja, al vindt ik Sitenaam: een beetje onnodig. In Symfony gebruiken we gewoon WjBlogBundle:Post:show wat we dan een logical name noemen die naar een Wj\BlogBundle\Controller\PostController::showAction() method verwijst.
Overigens zou ik de route config wat anders doen:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
show_post:
pattern: /blog/post/{id}
defaults: { _controller: WjBlogBundle:Post:show }
requirements:
_method: [ GET, POST ]
id: [0-9]*
pattern: /blog/post/{id}
defaults: { _controller: WjBlogBundle:Post:show }
requirements:
_method: [ GET, POST ]
id: [0-9]*
Het voordeel van bundles is dat je ook een eigen Config mapje erin kunt maken met een routing.yml bestand en dan in de globale routing.yml iets van:
Code (php)
1
2
2
blog_bundle:
Resource: @WjBlogBundle/Config/routing.yml
Resource: @WjBlogBundle/Config/routing.yml
Welke dan dat bestand inlaad, zo heb je al helemaal een afhankelijke bundle.
Het mooie van zo'n bundle is dat als je hem goed maakt je hem altijd kunt gebruiken. Symfony heeft zo een hele collectie aan geweldige bundles van andere mensen die je zo kunt inladen (http://knpbundles.com ). Ik laad vaak de FosUserBundle in en bijv. een SinatraAdminbundle en ik heb zo een Admin interface gemaakt.
Dus je wilt eigenlijk zeggen dat die Sitenaam aan de bundlenaam kan?
Ik snap alleen iets niet in je config, namelijk 'defaults'... waarom zou een controller een standaard waarde moeten hebben en kan je die niet 'gewoon' definen als controller?
En voor wat staat die '_' voor method en controller?
Thanks!
Code (php)
1
2
3
4
2
3
4
show_page:
pattern: /{slug}
defaults:
slug: home
pattern: /{slug}
defaults:
slug: home
Deze stel je in onder de defaults. En soms heb je ook requirements, een bepaalde placeholder moet aan voorwaarden voldoen. Deze stel je in onder requirements.
Nu is de controller eigenlijk niks meer dan een default waarde die bij die route hoort, vandaar dat Symfony en ZF hem bij de defaults gooien. De method is een requirement voor de route, vandaar dat die onder requirements staat.
De _ voor deze namen staat ervoor dat dit systeem namen zijn, het zijn geen parameters uit de route maar parameters die het framework gebruikt.
Je kan ook deze manier trouwens ook mooi de route variabel maken:
Code (php)
1
2
2
application:
route: /{_controller}
route: /{_controller}
Quote:
Dus je wilt eigenlijk zeggen dat die Sitenaam aan de bundlenaam kan?
Nee, een sitenaam heeft totaal geen nut voor een back-end applicatie. De bundles kunnen overal gebruikt worden en zijn zomaar wat componenten, dus nergens heb je die sitenaam nodig, omdat de applicatie niet aan een bepaalde site vast zit.