[PHP MVC] Waar veel gebruikte functies plaatsen ?

[Verwijderd]

Hoe een MVC in te richten is wel duidelijk bij veel mensen, uiteraard verschillen de MVC's in opbouw wel.

Ert vanuit gaande dat een MVC een controller_base en model_base heef waarbij er een controller directory is en een model_directory waarbij de controllers FOO_controller.php en de models FOO_model.php heten.

Om de juiste views te gebruiken heb je een folder FOO in de folder views nodig, dit gaat er dus uit zien als:

code:

+-/
  +-controller/
   | +-FOO_controller.php
  +-helpers/
   | +-model_helper.php
   | +-controller_helper.php
   | +-view_helper.php
  +-lib/
   | +-model_base.php
   | +-controller_base.php
   | +-router.php
  +-model/
   | +-FOO_model.php
  +-view/
   | +-FOO
      |+-index.php
      |+-secure.php
      |+-login.php
  +-index.php

Stel je hebt meedere view folders als FOO1, FOO2 waarin views staan welke je wil "beveiligen" met een user-level dan heb je hier een functie voor nodig om dit makkelijk te kunnen doen.

Ik ben nog in dubbio of ik dit via een query wil doen, dus kijken wat de de user-level is dmv een query of dit op te slaan in een sessie-variabele. Probleem van sessie-variabele is dat je vaak opniew moet inloggen om nieuwe rechten toe te passen... echter een query voor iedere pagina bezoek lijkt me logisch maar misschien wat overdreven.

Om terug te komen op mijn "probleem" is dat ik deze functies shared wil maken zodat ik deze overal makkelijk kan gebruiken zonder deze iedere keer in de desbetreffende controller te moeten zetten.

Ik vraag me echt af wat de beste optie is. Ik heb gedacht een functions.php te gebruiken en deze simpelweg in de index te includen en dan op die manier deze functies te gebruiken welke natuurlijk in een classe staan.

Het jammere van die oplossing is dat je dan queries in je functions.php gaat zetten en dit van een MVC niet echt de bedoeling is. Echter omdat je hier niet echt een model/controller constructie voor kunt maken die logisch is tov het MVC loop ik een beetje vast.

Het schijnt dat meerdere PHP-programmeurs hier met een eigen MVC tegenaan lopen. Je moet het eigenlijk tegen gaan om een "externe" functions file te maken maar het komt er op neer dat je vaak niet anders kan.

Wat is nu wijsheid om van deze functies bruikbaar te maken in iedere view/controller ? Deze functies kunnen dus vanalles doen, gebruik makelijk van queries, session checks, etc, welke je overal waar nodig wil toe kunnen passen op een nette manier.

[HuHu]

Dat soort dingen heten view/controllers helpers. Ik zie dat je al een mapje helpers hebt, dus dan zet je dat daar in.

Controleren of iemand wat mag zien kan middels een Access Control List (ACL). Dan maak je een AclViewHelper aan die kunt gebruiken om in de view te controleren of iemand iets mag zien.

[Verwijderd]

OK, jij zegt dus ook helpers

Maar wat vind jij dat je in die helper mag doen qua data ?

[HuHu]

Het lijkt mij dat zo'n helper bestaan uit 1 functie: isAllowed(). Dus als je in een view zit en je wilt afhankelijk van de rechten iets wel/niet renderen, dan roep je even simpel de isAllowed() aan om dat te controleren.

Hoe je die isAllowed() vervolgens implementeert is een tweede natuurlijk. Je kunt je ACL object singleton maken, hem opslaan in een Registry, een database-query doen, ophalen uit de session, enz...

Ik denk dat ik het ACL object eenmaal zou maken en hem vervolgens in een Registry opslaan, zodat je ViewHelper er bij kan.

[Verwijderd]

OK duidelijk maar jij vindt dus dat je in een helper best queries mag draaien en dergelijke ?

Nog even de keus maken wanneer ik ga includen voor dit soort zaken... in de index is altijd lekker makkelijk

[zwippie]

Kun je de ACL check niet beter doen in de controller dan in de view? Stel dat iemand user/delete?id=13 aanroept en de controller roept vrolijk het model aan om dit te doen, en pas in de view krijg je een melding: access denied. Dan ben je dus te laat.

Verder zou ik gewoon gaan experimenteren met je opbouw van helpers en libraries. Het is een beetje zoeken naar een vorm die je ligt.

Soms is het makkelijk om de wat meer 'universele' library classes in de libs dir te stoppen, om vervolgens veelgebruikte codefragmenten die die library gebruiken in een helper te stoppen.
Dus je hebt bv een ACL library gevonden die je in libs stopt, en in helpers maak je een klasse/bestand met functies die het gebruik van die ACL library makkelijk maken, speciaal voor de site die je nu maakt.

Aan de andere kant kan het ook voldoende zijn om je libraries en helpers te voorzien van goede namespacing.

En soms is het verschil tussen een helper en een libary gewoon niet duidelijk.

[Verwijderd]

zwippie schreef op zondag 22 november 2009 @ 18:56:

En soms is het verschil tussen een helper en een libary gewoon niet duidelijk.

Dat klopt, ik merk dit ook in jouw verhaal eigenlijk.

Een eigen vorm is altijd even wennen, want je ziet vaak "nee ! doe het zo" waar opzich niet altijd een reden voor is om het "zo" te doen.

Ik denk dat de helpers gebruiken zoals ze zijn zonder gekke libraries helemaal niet slecht is. Je houdt het overzichtelijk.

Over je voorbeeld, tuurlijk vang je die ingen op in je controller... de vraag was alleen waar zet je die functies neer om dit te doen

Voor de view praat ik over bijvoorbeeld menuopties welke je wel of niet wil laten zien aan de hand van een functie die checkt "wat" je bent.

[ Voor 10% gewijzigd door Verwijderd op 22-11-2009 19:10 ]

[Verwijderd]

Alsof MVC iets dergelijks afdwingt. Het is slechts een design pattern zoals er velen zijn, en voor internet-applicaties is de naam "MVC" sowieso gejat en omgebogen tot een methode, die niets eens direct veel met het oorspronkelijke pattern te maken heeft.

Erzijn nog zoveel meer design patterns, die vrijwel allemaal niet direct iets met MVC te maken hebben echter die er wel goed mee te integreren zijn.

"Controller directory", "Model directory", dat is allemaal bullshit die niet direct met MVC te maken heeft. Het is prima denkbaar dat je al die classes helemaal niet op zo'n manier in een directory kwakt. Dat wordt helaas meestal slecht begrepen, en er wordt meestal niet meer ingezien dat er meestal met één voorbeeld van een enigszins op MVC gelijkende implementatie wordt gewerkt.

Ik vraag me af hoeveel MVC-webdevelopers überhaupt het principe van dat specifieke design pattern kennen, en hoeveel er zijn die weleens een goed boek over design patterns hebben gelezen.

Het is jammer dat je zo worstelt met "functions" en "directories" die één specifieke interpretatie/implementatie je oplegt. Of eigenlijk die je jezelf oplegt.

Misschien moet je je business logic wel gewoon meer loskoppelen van de presentatie. Probeer het eens abstracter te zien en probeer te bedenken hoe de applicatie zou moeten werken als je een WUI had, maar ook een GUI en CLI.

[Verwijderd]

Verwijderd schreef op zondag 22 november 2009 @ 19:26:
Alsof MVC iets dergelijks afdwingt. Het is slechts een design pattern zoals er velen zijn, en voor internet-applicaties is de naam "MVC" sowieso gejat en omgebogen tot een methode, die niets eens direct veel met het oorspronkelijke pattern te maken heeft.


Erzijn nog zoveel meer design patterns, die vrijwel allemaal niet direct iets met MVC te maken hebben echter die er wel goed mee te integreren zijn.

"Controller directory", "Model directory", dat is allemaal bullshit die niet direct met MVC te maken heeft. Het is prima denkbaar dat je al die classes helemaal niet op zo'n manier in een directory kwakt. Dat wordt helaas meestal slecht begrepen, en er wordt meestal niet meer ingezien dat er meestal met één voorbeeld van een enigszins op MVC gelijkende implementatie wordt gewerkt.

Ik vraag me af hoeveel MVC-webdevelopers überhaupt het principe van dat specifieke design pattern kennen, en hoeveel er zijn die weleens een goed boek over design patterns hebben gelezen.

Tja, dit is een mening welke je zelf geeft aan de hand van een vorm welke ik gebruik. Dat doet opzich niet echt ter zake voor de vraag.

Het is jammer dat je zo worstelt met "functions" en "directories" die één specifieke interpretatie/implementatie je oplegt. Of eigenlijk die je jezelf oplegt.

Hoezo worstelt ? Ik vind de manier van mijn MVC echt super lekker werken, alleen vraag ik me af wat logisch is om dergelijke functies te plaatsen. Je kan zoveel kanten op, gewoon file die je grofweg include, of iets meer fancies... vandaar de vraag ook.

Misschien moet je je business logic wel gewoon meer loskoppelen van de presentatie. Probeer het eens abstracter te zien en probeer te bedenken hoe de applicatie zou moeten werken als je een WUI had, maar ook een GUI en CLI.

Dit heb ik je al zo vaak horen zeggen, echter ligt alles al erg los van elkaar voor een simpel MVC-frameowork. CLI en dergelijke kun je erbij halen om je verhaal wat meer waarde te geven maar geeft momenteel geen waarde aan de huidige situatie. Je zegt hier dus eigenlijk niet veel

[bigbeng]

Wat Cheatah volgens mij probeert te zeggen is dat je jezelf blind lijkt te staren op het toepassen van het MVC pattern. Het toepassen van gebruikersrechten is iets wat niet direct te maken heeft met MVC. Je geeft dus ook een boel meer context dan nodig is voor je vraag, met als gevolg dat je dus ook reactie daarop krijgt.

Terugkomend op jouw vraag, het shared maken van het autorisatie aspect van je applicatie lijkt mij een goed idee. Welke van de twee opties (query of sessie-caching) het beste werkt is afhankelijk van hoe je webapp gebruikt wordt. Hoe vaak verwacht je dat de rechten van een gebruiker aangepast worden? En hoe snel wil je dat verwerkt zien in je applicatie? Is het erg als de gebruiker een halve dag met zijn oude rechten werkt? Zo ja, wat zou een betere tijd zijn? Of moet het realtime? Heeft iedere view een database call nodig? Zo ja, is het erg als daar nog een call aan toegevoegd wordt voor user-rechten?

Dit zijn zomaar een paar vragen die in mij opkomen die je denk ik mee moet laten wegen in je beslissing.

[HuHu]

zwippie schreef op zondag 22 november 2009 @ 18:56:
Kun je de ACL check niet beter doen in de controller dan in de view? Stel dat iemand user/delete?id=13 aanroept en de controller roept vrolijk het model aan om dit te doen, en pas in de view krijg je een melding: access denied. Dan ben je dus te laat.

Daarvoor maak je dan een ActionHelper en een ViewHelper. In de controller gebruik je de AclActionHelper om te zien of de actie uitgevoerd mag worden. In de view gebruik je de AclViewHelper om te zien of je een linkje naar een bepaalde action wel/niet mag renderen.

Verder zou ik gewoon gaan experimenteren met je opbouw van helpers en libraries. Het is een beetje zoeken naar een vorm die je ligt.

Soms is het makkelijk om de wat meer 'universele' library classes in de libs dir te stoppen, om vervolgens veelgebruikte codefragmenten die die library gebruiken in een helper te stoppen.
Dus je hebt bv een ACL library gevonden die je in libs stopt, en in helpers maak je een klasse/bestand met functies die het gebruik van die ACL library makkelijk maken, speciaal voor de site die je nu maakt.

Aan de andere kant kan het ook voldoende zijn om je libraries en helpers te voorzien van goede namespacing.

En soms is het verschil tussen een helper en een libary gewoon niet duidelijk.