[Zend Framework] Zend_Acl als model

[nika]

Ik vraag me af waarom Zend_ACL extensions altijd worden toegevoegd aan de library van applications. Zijn Zend_ACL eigenlijk niet een model?

Vaak zie je deze implementatie

code:

class My_ACL extends Zend_ACL {

    public function __construct() {
        $this->addRole('role1');
        $this->addRole('role2');

        $this->addResource('resource1');

        $this->allow('role1', 'resource1');
    }
}

Is dit niet eigenlijk business logic? Die dus thuis hoort in de model map (simpel gezegd)?

[Cartman!]

Ik vind het sowieso niet horen in je library aangezien de rollen/resources die je toevoegd horen bij de app die je maakt. Nu vind ik Zend_Acl sowieso niet lekker werken, ik heb een eigen implementatie gemaakt van RBAC met alle data in een database voor makkelijk beheer. Persoonlijk vind ik t ook geen model overigens, het is gewoon statische data nu die gelden voor je app, ik zou t gewoon maken als onderdeel van je bootstrap.

[nika]

Hmmm,

ik vind het toch echt iets meer dan alleen statische data. Welke rol wel en niet toegang heeft tot welke resource vind ik wel degelijk business logic. Zeker als je ook nog eens werkt met dynamic assertions.

Wat ik wel mooi vind aan Zend_ACL is het eenvoudig kunnen werken met Zend_Acl_Role_Interface en Zend_Acl_Resource_Interface.

Maar ik ben gelukkig niet gek in dat ik denk dat Zend_ACL extensions in de library wel heel vreemd zijn.

[kokx]

Je hebt hierin grotendeels gelijk. Zelf laat ik bepaalde models vaak de Zend_Acl interfaces implementeren.

Een user kan bijvoorbeeld gewoon Zend_Acl_Role_Interface implementeren.

[mithras]

Nee, ik zie ACL niet iets als onderdeel van je model. Een role implementeer ik als een model. Een resource is ook een model. Zelfs mijn permissies die de koppeling tussen role en resource vormen dmv een actie is een model. Maar de ACL zelf niet.

Verder is er gewoon een applicatie-specifieke library waarin ik applicatie-specifieke zaken stop die wel in een library thuishoren. Application resources, view helpers, dat soort zaken zijn prima dingen die je in een library kunt stoppen.

Zelf heb ik een frontcontroller plugin die ACL initialiseert (App_Frontcontroller_Plugin_Acl). Hij zoekt de huidige role en resource en geeft die vervolgens aan mijn applicatie ACL object (App_Acl). Die koppelt het geheel aan elkaar en retourneert een Zend_Acl. De frontcontroller plugin checkt vervolgens of je de juiste permissie hebt.

[nika]

Ik kan me ten dele vinden in je oplossing Mithras. En ik denk dat het voor eenvoudige applicaties ook wel zo werkt. Echter, wanneer je een dynamisch rollen systeem hebt ga je regelmatig je rol - resource koppelingen aanpassen. Dan kom je volgens mij meer richting models.

Overigens gebruik ik net als jij een frontcontroller plugin, gecombineerd met controller based assertions (bijv. is deze gebruiker gemachtigd om dit bericht te editen -> toon buttons wel/niet).

Hoe denken jullie over zend_acl assertions in de view? Done of niet?

[mithras]

nika schreef op zaterdag 25 september 2010 @ 11:54:
Ik kan me ten dele vinden in je oplossing Mithras. En ik denk dat het voor eenvoudige applicaties ook wel zo werkt. Echter, wanneer je een dynamisch rollen systeem hebt ga je regelmatig je rol - resource koppelingen aanpassen. Dan kom je volgens mij meer richting models.

Ik heb dus ook users/groups (roles) en pages/categories (resources) en permissies die in mijn domain layer zitten en ik uit een db trek hoor

Hoe denken jullie over zend_acl assertions in de view? Done of niet?

Kan prima, je moet eenmaal checken of je permissies hebt om een edit button te laten zijn (bijv.). Dat kan je allemaal in je controller stoppen en een boolean naar je view passen, een view helper kan imho hetzelfde doen.

[nika]

Agreed. Ik word af en toe paranoid als het gaat om het zuiver toepassen van MVC