Správne pochopenie významu AdminModule

mbskot

Ahojte,
prednedávnom som čítal článok od Patrik Votoček AdminModule vs. BackendPresenter, kde som zistil, že som zle pochopil význam AdminModule. Pls mohol by mi niekto vysvetliť/ ukázať ako by mal vyzerať taký AdminModule?

Pochopil som to tak, že vo Fronte mám presentery, ktoré sú dostupné pre verejnosť(či už prihlásenú, alebo nie). Ak mám presenter FrontModule\ArticlePresenter, tak je len jeden, žiadny iný a v ňom mám všetky actiony a handlery, ktoré potrebujem. Každý prihlásený užívateľ môže robiť CRUD s článkami ak má na to práva, je autorom atď.
AdminModule používam striktne len na údržbu systému(správa užívateľov a ich oprávnení).

nanuqcz

Pochopil som to tak, že vo Fronte mám presentery, ktoré sú dostupné pre verejnosť(či už prihlásenú, alebo nie). Ak mám presenter FrontModule\ArticlePresenter, tak je len jeden, žiadny iný a v ňom mám všetky actiony a handlery, ktoré potrebujem. Každý prihlásený užívateľ môže robiť CRUD s článkami ak má na to práva, je autorom atď.
AdminModule používam striktne len na údržbu systému(správa užívateľov a ich oprávnení).

Ahoj, pochopil jsi to dobře ;-) Patrik Votoček používá jen trochu jinou strukturu, která ale ve výsledku zase dělí aplikaci na presentery, které jsou určeny pro veřejnost a na presentery, které jsou určeny pro administrátory (backend).

Správně jsou podle mě obě varianty a je na každém progamátorovi, která varianta mu přijde hezčí.

Příklad: „Klasická“ struktura:

FrontModule:
    HomepagePresenter
    ArticlesPresenter
    UsersPresenter
AdminModule:
    HomepagePresenter
    ArticlesPresenter
    UsersPresenter

Alternatvní struktura:

HomepageModule
    FrontPresenter    // odpovídá FrontModule:HomepagePresenter při použití klasické struktury
    BackendPresenter  // odpovídá AdminModule:HomepagePresenter při použití klasické struktury
ArticlesModule
    FrontPresenter    // odpovídá FrontModule:ArticlesPresenter při použití klasické struktury
    BackendPresenter  // odpovídá AdminModule:ArticlesPresenter při použití klasické struktury
UsersModule
    ...

Obsahy presenterů budou ve výsledku stejné, mění se jen jejich název a použitá namespace.

mbskot

Ďakujem za odpoveď :),
pri tej „klasickej štruktúre“ ako mám chápať AdminModule\ArticlesPresenter, čo v tom robím?
Ak mám vo FronteModule\ArticlesPresenter, ktorý má všetky actiony, tak načo mi je ten v Admine?
Presenter v Admine dedí od Presentera vo Fronte?
Tomuto nerozumiem.

Michal Vyšinský

Ten v AdminModulu zajišťuje např. přidání nového článku, editace, mazání. Prostě akce, které by „normální“ uživatel/návštěvník webu neměl provést.

mbskot

no a tu bude problém, že som to všetko natrepal do jedného a pri každom handler/signal som dal overovať právomoci užívateľa.

A ako to je s editačnými značkami(edit, delete)? Ak som vo Fronte a som prihlásený, mám práva editácie článkov, linky smerujú na actiony do AdminModule\ArticlesPresenter?

nanuqcz

mbskot napsal(a):

no a tu bude problém, že som to všetko natrepal do jedného a pri každom handler/signal som dal overovať právomoci užívateľa.

No vidíš, a ty používáš ještě třetí způsob, který je taky svým způsobem správný :-)

Rozdělení na AdminModule / FrontModule (případně FrontPresenter a BackendPresenter) má význam tehdy, když chceš například, aby měla administrace jinou grafiku, než uživatelská část. Pak to můžeš pomocí modulů takto oddělit ;-)

mbskot

okay, tak ak to čo používam nie je zlé riešenie, tak ho meniť nebudem :). Len tie overovačky na x miestach sa mi nepáčia, to ešte nejako vylepším. thx :)

nanuqcz

Můžeš použít např ACL a ověřování dát do BasePresenteru (ze kterého by měly všechny ostatní presentery dědit)

mbskot

používam ACL. U mňa sa overuje či užívateľ je autorom, alebo má právo editovať cudzie články a musím to overovať podstate všade(editácia, mazanie, priloženie prílohy…). To isté potom v CategoryPresenter v MenuPresenter a nepáči sa mi to. Rozmýšľam nad niečim takýmto:

abstract class BaseItemPresenter extends AuthorizationPresenter {
	protected $item = NULL;

	public function actionDefault($id) {
		$this->item = $this->context->items->find($id);

		if(!$this->user->isAllowed($this->item, 'view')) {
			$this->checkAccessDeniedReason();
		}
	}

	public function actionCreate($parentId = NULL) {
		if(!$this->user->isAllowed($this->type, 'crud')) {
			$this->checkAccessDeniedReason();
		}
	}

	public function actionEdit($id) {
		$this->item = $this->context->items->find($id);

		if(!$this->user->isAllowed($this->item, 'crud')) {
			$this->checkAccessDeniedReason();
		}
	}

	public function actionDelete($id) {
		$this->item = $this->context->items->find($id);

		if(!$this->user->isAllowed($this->item, 'crud')) {
			$this->checkAccessDeniedReason();
		}
	}
}

class ArticlePresenter extends BaseItemPresenter {
	protected final $type = 'article';

	public function actionDefault($id) {
		parent::actionDefault($id);
		// todo
	}

	public function actionCreate($parentId = NULL) {
		parent::actionCreate($parentId);
		// todo
	}

	public function actionEdit($id) {
		parent::actionEdit($id);
		// todo
	}

	public function actionDelete($id) {
		parent::actionDelete($id);
		// todo
	}
}

Editoval mbskot (26. 1. 2012 14:11)

mbskot

Rozmýšľam ešte nad jednou štruktúrou(podobná Patrikovej), kde každý celok by bol ako „balíček“ ->

Article\
	components
	forms
	models
	presenters
	templates
Menu\
	components
	forms
	models
	presenters
	templates
Forum\
	components
	forms
	models
	presenters
	templates

Čo tým hľadám? Moc sa mi nezdá dobré miešať hrušky s jablkami(ak nejdú do suda :D).
Keď sú napr. všetky entity(s Doctrine) v jednom adresári, je ich tak akosi moc a je to neprehľadné. Mohol by som systém adresárovo takto rozhodiť?