[ZF] Custom module systeem

[ZpAz]

Scroll naar onderen voor nieuwe post, of klik hier

Ik ben bezig met het ontwikkelen van een CMS systeem voor mezelf en toekomstige klanten, welke gebruik gaat maken van het Zend Framework. Nu wil ik dat het systeem volledig modulair wordt opgebouwd, zodat ik makkelijk items kan hergebruiken, toevoegen, verwijderen.

Nu heb ik als structuur hiervoor dit gekozen.

*
In het plaatje staat de eerste config.xml op de verkeerde locatie, deze moet in de 'core' map staan ipv in de 'core/frontend' map.

Nu vroeg ik me af, hoe kan ik er voor zorgen dmv Routes (dat lijkt me de oplossing) dat hij bij url

http://test.nl/index/

De controller hier weg haalt:

/modules/core/frontend/controllers/IndexController.php

Maar hij bijvoorbeeld bij de url

http://test.nl/search/

de controller haalt uit:

/modules/search/frontend/controllers/SearchController.php

Maar wanneer een url begint met 'admin' (dus http://test.nl/admin/search/) moet hij niet in het mapje 'frontend' kijken van de betreffende controller, maar in het mapje 'backend' welke een zelfde structuur heeft als de backend.

Dmv de standaard Zend_Framework dingen kan je wel een structuur ala:

/modules/core/controllers/IndexController.php
/modules/search/controllers/SearchController.php

doen, maar dan moeten de 'admin' controllers welke bijvoorbeeld bij de search module horen, in een aparte module map worden gestopt. (Dan krijg je dus dit idee)

/modules/core/controllers/IndexController.php
/modules/search/controllers/SearchController.php

/modules/admin/controllers/IndexController.php
/modules/admin/controllers/SearchController.php

Terwijl ik graag bij de 'search' module, de admin (backend) en frontend in dezelfde module map wil hebben, zodat ik maar een enkele map hoef toe te voegen, of te verwijderen, voor de betreffende functionaliteit.

Dus ik wil graag, deze structuur:

/modules/core/controllers/frontend/IndexController.php
/modules/core/controllers/backend/IndexController.php

/modules/search/controllers/frontend/SearchController.php
/modules/search/controllers/backend/SearchController.php

Ik hoop dat ik duidelijk ben.

[ Voor 5% gewijzigd door ZpAz op 06-10-2009 16:14 ]

[Matis]

Ik denk dat je je eens moet verdiepen in RewriteRules en .htaccess

[Verwijderd]

Zend heeft een zeer uitgebreide router suite. Mogelijk moet per custom url wel wat instellen, maar mbv Regex-en kun je ontzettend flexibel je url's opbouwen. (Een voordeel is dat je ook andersom URL's kunt genereren met behulp van je Router, dus je voert controller/action/module in of zelf alleen de route naam en je krijgt een correcte url terug. Bekijk hiervoor de url viewhelper.

http://framework.zend.com...nd.controller.router.html

Edit: na je post nog een keer gelezen te hebben is het me duidelijk dat je mogelijk ook problemen hebt om je controllers te vinden in je huidige structuur. Mogelijk moet je elke dir apart toevoegen met addControllerDirectory op je front controller, of misschien kun je dit in een controller_plugin doen.

[ Voor 58% gewijzigd door Verwijderd op 24-09-2009 15:56 ]

[Matis]

@TS, je weet dat er risico's kleven aan het "volledig baseren op" het ZF.

[Verwijderd]

Matis schreef op donderdag 24 september 2009 @ 15:53:
@TS, je weet dat er risico's kleven aan het "volledig baseren op" het ZF.

Zoals?

[ Voor 15% gewijzigd door Verwijderd op 24-09-2009 16:19 ]

[iH8]

Matis schreef op donderdag 24 september 2009 @ 15:53:
@TS, je weet dat er risico's kleven aan het "volledig baseren op" het ZF.

je wekt ook mijn nieuwsgierigheid. vertel op

[Matis]

iH8 schreef op donderdag 24 september 2009 @ 16:38:
[...]


je wekt ook mijn nieuwsgierigheid. vertel op

Ik was ff onderweg naar huis...

Je weet nooit wat er met zo'n Framework gaat gebeuren. Voor hetzelfde geld trekken ze er morgen de stekker uit. (Dit is hypothetisch mogelijk, en tevens worst case)
Wat er ook kan gebeuren is dat er in nieuwe versies functies weggehaald/aangepast worden, waardoor de integriteit van je systeem kan veranderen.
Daarbij moet je nog de afweging maken dat (wanneer ZF een nieuw versienummer krijgt) je meteen de nieuwe versie wilt pushen in je huidige CMS.

[iH8]

Matis schreef op donderdag 24 september 2009 @ 16:42:
[...]

Ik was ff onderweg naar huis...

Je weet nooit wat er met zo'n Framework gaat gebeuren. Voor hetzelfde geld trekken ze er morgen de stekker uit. (Dit is hypothetisch mogelijk, en tevens worst case)
Wat er ook kan gebeuren is dat er in nieuwe versies functies weggehaald/aangepast worden, waardoor de integriteit van je systeem kan veranderen.
Daarbij moet je nog de afweging maken dat (wanneer ZF een nieuw versienummer krijgt) je meteen de nieuwe versie wilt pushen in je huidige CMS.

erhmz. je bent dus geen voorstander van frameworks. als je in elk topic over ZF of welk ander framework dit wil melden dan ben je nog wel even bezig. over wat je zegt: is dat niet met het gebruik van elk ander framework, symphony, cake, codeigniter ook? of bij het gebruik van een bestaands CMS zoals Joomla of Drupal. of heb je het hier over Zend specifiek? voor hetzelde geld stoppen ze morgen met PHP development. zijn we allemaal de sjaak. ik denk als je ergens safe mee zit dan is het wel ZF aangezien dat van Zend zelf is net als PHP.

[YopY]

Matis schreef op donderdag 24 september 2009 @ 16:42:
[...]

Ik was ff onderweg naar huis...

Je weet nooit wat er met zo'n Framework gaat gebeuren. Voor hetzelfde geld trekken ze er morgen de stekker uit. (Dit is hypothetisch mogelijk, en tevens worst case)
Wat er ook kan gebeuren is dat er in nieuwe versies functies weggehaald/aangepast worden, waardoor de integriteit van je systeem kan veranderen.
Daarbij moet je nog de afweging maken dat (wanneer ZF een nieuw versienummer krijgt) je meteen de nieuwe versie wilt pushen in je huidige CMS.

Ja, maar dat is met alles zo. Ga je de PHP api niet gebruiken omdat ze die misschien aan gaan passen?

ZF is open source - in het ergste geval moet je het zelf aanpassen. Worden functies weggehaald of aangepast? Dan blijf je bij de bestaande versie, sim-pel.

Jij bent zeker een van de vele figuren die zegt 'ja ik maak m'n eigen php framework en cms en forum', of niet?

@ topic, is al beantwoord, je kunt heel veel met de router. Je zou misschien een generieke plugin controller moeten maken die een request naar een bepaalde pagina routeert naar een specifieke plugin controller, maar dat lijkt me redelijk eenvoudig.

[storeman]

met iH8, het is gelukkig volledig open source. Daarnaast heb je natuurlijk gewoon een werkend framework die gewoon onder een goede licentie is uitgegeven. Dus daar kun je altijd mee verder. De huidige componenten zijn gewoon goed en hebben niet zo veel updates meer nodig, dat zal vooral voor nieuwe functionaliteit zijn.

ontopic:
Hoe je het nu hebt ingericht is niet al te best. Ik heb zelf ook een systeem zo ingericht, maar zo is het nooit bedoeld. Uiteraard kun je het wel misbruiken zodat het werkt, maar zo is het nooit bedoeld.
De modules zijn bedoeld om verschillende sites mee te maken die naast elkaar kunnen draaien, in elke submap van de map modules (dus iedere module), horen gewoon alle mappen te staan die je normaal bij een simpel project hebt. Zoals models, forms, layouts, views en controllers. Het idee is dus een volledige scheiding tussen alle componenten.

Wat je wilt is niet fout, maar zo is het niet bedoeld.

[mithras]

Matis schreef op donderdag 24 september 2009 @ 16:42:
[...]

Je weet nooit wat er met zo'n Framework gaat gebeuren. Voor hetzelfde geld trekken ze er morgen de stekker uit. (Dit is hypothetisch mogelijk, en tevens worst case)
Wat er ook kan gebeuren is dat er in nieuwe versies functies weggehaald/aangepast worden, waardoor de integriteit van je systeem kan veranderen.
Daarbij moet je nog de afweging maken dat (wanneer ZF een nieuw versienummer krijgt) je meteen de nieuwe versie wilt pushen in je huidige CMS.

Dit slaat op niet heel veel meer dan nergens

a) je hebt nu een werkende versie. Ook al stopt de ontwikkeling, jij kan met die huidige versie nog gewoon werken hoor
b) Nieuwe functionaliteiten komen in nieuwe versies. Als je daardoor met een bc break zit, wordt dat toch altijd aangekondigd. Aanpassen of niet gebruiken dus
c) Nieuwe 3rd party versies gelijk live pushen brr, ik hou me liever aan ons standaard ontwikkeltraject. Development -> testing -> staging -> live dus

@TS: Je gebruikt de modules niet echt als modules, maar daar heb je nog een onderverdeling in. Lijkt me niet heel erg handig. Je hebt wel in Zend_Controller_Front de optie "moduleControllerDirectoryName". Standaard is dit controllers, maar dit kan je aanpassen.
Met een configuratie kan je kijken of je de front- of backend wil benaderen. En op basis daarvan de moduleControllerDirectoryName omzetten.

[iH8]

YopY schreef op donderdag 24 september 2009 @ 16:54:

@ topic, is al beantwoord, je kunt heel veel met de router. Je zou misschien een generieke plugin controller moeten maken die een request naar een bepaalde pagina routeert naar een specifieke plugin controller, maar dat lijkt me redelijk eenvoudig.

als je dat werkend hebt zou ik hier graag een voorbeeldje zien. ik kan me niet eens verplaatsen in wat je bedoeld. je wil modules in modules duwen? als het technisch al mogelijk is werken dingen zoals dit dan nog:

PHP:

$this->_forward('action', 'controller', 'module', params);

zo zit er wel meer functionaliteit in ZF welke blind uit gaat van een action/controller/module structuur. ik denk dat je hopeloos vast komt te zitten. ik heb zoiets nog nooit eerder gezien.

[Matis]

How, begrijp me niet verkeerd. Ik ben groot fan van ZF.

Helaas wordt het weer verkeerd geïnterpreteerd.

YopY schreef op donderdag 24 september 2009 @ 16:54:
Jij bent zeker een van de vele figuren die zegt 'ja ik maak m'n eigen php framework en cms en forum', of niet?

Slechte dag gehad?

[ Voor 185% gewijzigd door Matis op 24-09-2009 17:04 ]

[Verwijderd]

iH8 schreef op donderdag 24 september 2009 @ 17:00:
[...]


als je dat werkend hebt zou ik hier graag een voorbeeldje zien. ik kan me niet eens verplaatsen in wat je bedoeld. je wil modules in modules duwen? als het technisch al mogelijk is werken dingen zoals dit dan nog:

PHP:

$this->_forward('action', 'controller', 'module', params);

zo zitten er wel meer functionaliteit in ZF welke blind uit gaat van een action/controller/module structuur. ik denk dat je hopeloos vast komt te zitten. ik heb zoiets nog nooit eerder gezien.

Een voorbeeld waar ik het zelf voor gebruik:
Ik heb een simpele blog gebouwd, met daarin verschillende categoriëen. Alle categoriëen wijzen uiteraard naar dezelfde controller, maar ik wil de url's wel 'mooi' hebben. Ik wil bijvoorbeeld dat de urls
host/articles
host/news
host/code

allemaal naar
module = default
controller = posts
action = index

verwijzen, en bovendien een parameter 'section' meegeven welke ik gebruik om onderscheid te maken tussen de verschillende types posts. Deze zijn gelukkig makkelijk te routen:

PHP:

$router->addRoute('news', new Zend_Controller_Router_Route('news', array('controller'=>'posts', 'section'=>SECTION_NEWS)));
$router->addRoute('articles', new Zend_Controller_Router_Route('articles', array('controller'=>'posts', 'section'=>SECTION_ARTICLES)));
$router->addRoute('code', new Zend_Controller_Router_Route('code', array('controller'=>'posts', 'section'=>SECTION_CODE)));

Als ik vervolgens in een url nodig heb doe ik in mijn view

PHP:

$this->url(array(), 'news');

Om een post te zien wil ik de url
host/view/13/titel/
hebben. Ik heb de volgende route:

PHP:

$router->addRoute('view',
                    new Zend_Controller_Router_Route_Regex('view/(\d+)(/.+)?',
                        array('controller'=>'posts', 'action'=>'view'),
                        array(1=>'id', 2=>'title'),
                        'view/%d/%s'));

Welke ik bij url's zo kan aanroepen:

PHP:

$this->url(array( 'id'=>13, 'title'=>'titel'), 'view')

Routes werken 2 kanten op (dankzij de sprintf string bij RegexRoutes). Het voordeel hiervan is dat je url's helemaal kunt omgooien, en het maar op 1 plek hoeft te doen. Als de parameters maar hetzelfde blijven.
Hoe het werkt met _forward weet ik niet zeker, omdat dit toch een interne functie is, dus weinig met de representatie van de urls te maken heeft (volgens mij herschrijft _forward deze sowieso niet?).

Hoe dit vervolgens zich verhoudt met het probleem van de ts weet ik niet zeker, maar als je de controllers gewoon met de hand of met een plugin registreert moet je ze gewoon kunnen aanroepen als normale controllers die automatisch zijn gevonden lijkt me?

[iH8]

dat dat kan weet ik, ik gebruik zelf ook gewoon de MVC met eigen routes maar de TS wil dit:

ZpAz schreef op donderdag 24 september 2009 @ 15:46:

Dus ik wil graag, deze structuur:

/modules/core/controllers/frontend/IndexController.php
/modules/core/controllers/backend/IndexController.php

/modules/search/controllers/frontend/SearchController.php
/modules/search/controllers/backend/SearchController.php

en dat zie ik dus niet gebeuren.

[mithras]

iH8 schreef op donderdag 24 september 2009 @ 18:05:
en dat zie ik dus niet gebeuren.

Het zou dus wel kunnen als je de moduleControllerDirectoryName aanpast, maar ik weet niet of het wordt toegestaan dat je de naam ook een folder mag bevatten. Dan kan je namelijk per requets switchen van "frontend/controllers" naar "backend/controllers".

Die switch vang je op. Dan kan je bijv. in je bootstrap dit al wisselen. Enig probleem: je kan in je bootstrap nog niet met routes aan de gang gezien je de applicatie nog niet run'd Misschien een frontController plugin, maar ik weet niet of het switchen tijdens zo'n plugin nog wel een goed idee is

[ Voor 28% gewijzigd door mithras op 24-09-2009 18:14 ]

[iH8]

mithras schreef op donderdag 24 september 2009 @ 18:12:
[...]
Het zou dus wel kunnen als je de moduleControllerDirectoryName aanpast, maar ik weet niet of het wordt toegestaan dat je de naam ook een folder mag bevatten. Dan kan je namelijk per requets switchen van "frontend/controllers" naar "backend/controllers".

Die switch vang op. Dan kan je bijv. in je bootstrap dit al wisselen. Enig probleem: je kan in je bootstrap nog niet met routes aan de gang gezien deze nog niet dispatched zijn. Misschien een frontController plugin, maar ik weet niet of het switchen tijdens zo'n plugin nog wel een goed idee is

brrrrrr. daar wil ik niet aan. of tenminste. nog niet nodig gehad, en volgens mij gelukkig. ik houd van simpel.

[Verwijderd]

iH8 schreef op donderdag 24 september 2009 @ 18:05:
dat dat kan weet ik, ik gebruik zelf ook gewoon de MVC met eigen routes maar de TS wil dit:

[..]
en dat zie ik dus niet gebeuren.

Misschien met een custom dispatcher en een module namespacing als core_frontend en core_backend die vervolgens naar de gewenste directory structuur word om gebouwd? Weet het niet zeker, ik moet zeggen dat ik ook niet zoveel ervaring hier mee heb. Het lijkt me alleen sterk dat het niet kan (al zul je inderdaad wel met de module-controller-action chain moeten blijven werken, anders werkt de rest van de ZF MVC klassen niet meer lekker)

[ZpAz]

storeman schreef op donderdag 24 september 2009 @ 16:56:
met iH8, het is gelukkig volledig open source. Daarnaast heb je natuurlijk gewoon een werkend framework die gewoon onder een goede licentie is uitgegeven. Dus daar kun je altijd mee verder. De huidige componenten zijn gewoon goed en hebben niet zo veel updates meer nodig, dat zal vooral voor nieuwe functionaliteit zijn.

ontopic:
Hoe je het nu hebt ingericht is niet al te best. Ik heb zelf ook een systeem zo ingericht, maar zo is het nooit bedoeld. Uiteraard kun je het wel misbruiken zodat het werkt, maar zo is het nooit bedoeld.
De modules zijn bedoeld om verschillende sites mee te maken die naast elkaar kunnen draaien, in elke submap van de map modules (dus iedere module), horen gewoon alle mappen te staan die je normaal bij een simpel project hebt. Zoals models, forms, layouts, views en controllers. Het idee is dus een volledige scheiding tussen alle componenten.

Wat je wilt is niet fout, maar zo is het niet bedoeld.

Ik wil ook 'alles' scheiden (ala, het zoekgedeelte krijgt eigen views, modules, controllers), en via wat code wordt deze dan ingevoegd in de layout, zodat ik later gewoon 'de zoekmodule' kan kopieren en hergebruiken, evt met kleine wijzigingen, maar zodat ik niet steeds alles weer hoef te programmeren

Leek mij juist wel een goede oplossing, scheiding tussen de diverse modules, en evt een aantal 'default modules'.

[ZpAz]

Nieuwe Post

En meteen een kickje. Okee, ik heb nu een 'front-controller-plugin' geschreven, welke aan de hand van de meegestuurde $reqeust kijkt welke controller en functie wordt aangeroepen in de url.

Dus in het standaard geval heb je zoiets:

http://site.nl/controller/actie/

Dit krijg ik dan ook netjes te zien, nu wil ik dat hij dan een andere controller gebruikt uit een evt andere directory. Uit mijn eigen (laten we zeggen tabel) kijk ik welke controller en actie daadwerkelijk moet worden uitgevoerd.

Hierin staat (voorbeeld) dit. (Ik gebruik niet daadwerkelijk tabellen, maar maakt het voor het voorbeeld makkelijker).

|-------------------------|------------------------|---------------------|
|-------adres-------|----controller----|-------action-------|
|-/controller/actie/-|-Othercontroller-|---otherAction--|
|-------------------------|------------------------|---------------------|

In dit geval moet hij dan dus als de controller 'controller' is en de action 'actie' is, de controller 'Othercontroller' gebruiken, en de action daarvan 'otherAction'. Nu is dit prima op te lossen met Zend_Router, maaar.. het punt waar ik tegenaanloop is dat de routes die ik in mijn plugin (front controller plugin) toevoeg, niet worden 'meegenomen'. Alleen als ik de routes defineer in de Bootstrap, of index worden deze meegenomen.

Is er niet een 'pre-router-hook' waar je al wel kan bij de request object welke de aangevraagde controller en action kan? Want ik heb nu alles werken, op dat punt na. De routes worden niet meer aangeroepen, welke in de front-controller-plugin zijn toegevoegd.

[mithras]

ZpAz schreef op dinsdag 06 oktober 2009 @ 16:08:
Nieuwe Post

En meteen een kickje. Okee, ik heb nu een 'front-controller-plugin' geschreven, welke aan de hand van de meegestuurde $reqeust kijkt welke controller en functie wordt aangeroepen in de url.

Dus in het standaard geval heb je zoiets:

http://site.nl/controller/actie/

Dit krijg ik dan ook netjes te zien, nu wil ik dat hij dan een andere controller gebruikt uit een evt andere directory. Uit mijn eigen (laten we zeggen tabel) kijk ik welke controller en actie daadwerkelijk moet worden uitgevoerd.

Hierin staat (voorbeeld) dit. (Ik gebruik niet daadwerkelijk tabellen, maar maakt het voor het voorbeeld makkelijker).

|-------------------------|------------------------|---------------------|
|-------adres-------|----controller----|-------action-------|
|-/controller/actie/-|-Othercontroller-|---otherAction--|
|-------------------------|------------------------|---------------------|

In dit geval moet hij dan dus als de controller 'controller' is en de action 'actie' is, de controller 'Othercontroller' gebruiken, en de action daarvan 'otherAction'. Nu is dit prima op te lossen met Zend_Router, maaar.. het punt waar ik tegenaanloop is dat de routes die ik in mijn plugin (front controller plugin) toevoeg, niet worden 'meegenomen'. Alleen als ik de routes defineer in de Bootstrap, of index worden deze meegenomen.

Is er niet een 'pre-router-hook' waar je al wel kan bij de request object welke de aangevraagde controller en action kan? Want ik heb nu alles werken, op dat punt na. De routes worden niet meer aangeroepen, welke in de front-controller-plugin zijn toegevoegd.

Bekijk het flow diagram van het framework eens: http://www.php-profession...9/01/zf-flow-diagram1.png. Er zijn er nog wel meer, maar dit is een simpele die ook nog eens de belangrijkste dingen goed weergeeft. Ik weet niet welke hook je gebruikt van de fontcontroller plugin, maar alles na de routing gaat natuurlijk niet meer lukken (tenminste, als je routes gaat toevoegen)

Daarnaast: waarom wil je dat /controller1/action1 een /controller2/action2 wordt Gebruik dan gewoon die laatste uri

In mijn applicatie (cms) wil je dat alle routes door de gebruiker in te voeren zijn. Ik gebruik een application resource die alle pagina's als routes (en navigatie) inlaadt. Dan zit je nog voor je dispatch loop