Práce s uživatelem – správný postup?

akadlec

Měl bych na vás, zdejší nette guru jeden dotaz. Ve své aplikaci řeším to jak mít k dispozici vždy čerstvá data v proměnné $user která je instancí \Nette\Security\User. Potřeboval sem mít kdykoliv k dispozici vešekeré údaje co má uživatel u sebe (username, email, jmeno, adresu, atd.)

V prvním řešení jsem měl pouze poděděnou class Identity kde jsem si vytvořil pole dat co jsem potřeboval a tyk pak předal Identitě z nette. Z počátku to bylo ok, ale vzhledem k tomu že používám doctrine tak mám v entitě uživatele nějaké další koleckce atd.

Takže jsem provedl další verzi a to poděděním UserStorage a úpravě tak aby docházelo vždy k refreshi entity, tj. při načtení stránky se mi vždy načte entita uživatele a tím mám k dispozici „čerstvá“ data.

Když už jsem měl takto upravený User objekt, napadlo mě jej začít využívat napříč celou appkou a tak ve formech editace provedu změnu dat přímo v tomto objektu který pak uložím.

Mám tedy např.:

function formSubmitted($form)
{
	$values =.....
	....
	$this->user->identity
		->setEmail($values['email']
		->setGender($values['gender']
		...
		->setUsername($values['username']);

	$this->user->save()
}

V objektu uživatele mám tedy k dispozici i metodu pro uložení, která si v podstatě z identity vytáhne samotnou entitu uživatele a provede její uložení.

A tak se ptám, je toto tedy správný směr? Nebo na to jdu špatně?

David Matějka

Takže jsem provedl další verzi a to poděděním UserStorage a úpravě tak aby docházelo vždy k refreshi entity, tj. při načtení stránky se mi vždy načte entita uživatele a tím mám k dispozici „čerstvá“ data.

a tady bych skoncil :)

pokud se po kazdem nacteni stranky refreshne entita, je zbytecne ji rucne upravovat. navic uvedom si, ze muzes vzdy upravovat jen identitu vazanou na aktualni session. pokud tedy treba jako administrator budes chtit upravit uzivatele (treba ho zablokovat, zmenit mu role..), tak by rucnim upravovanim identity zmena nesla provest. ale kdyz mas upravenej userstorage, kterej vzdy nacte aktualni data, tak to neni problem.

akadlec

No možná jsem to trochu zmateně popsal ;) Mám upravený UserStorage co obnovuje data o uživateli a k těm datům přistupuju přes tu identitu, např.:

$this->user->identity->email
$this->user->identity->defaultAddress->city

Takže přistupuju k samotné doctriňácké entitě. A pokud jako admin cokoliv tomu uživateli změním tak se to samo projeví i u toho uživatele. Ta identita je v podstatě pro mě nyní „obálka“ nad tou entitou aby byla zachována původní funkčnost z Nette.

Šaman

Taky by mě zajímalo, jaký je best practice pro práci s uživatelem jako ORM entitou.
$presenter->user je spíš technologická a ještě navíc active záležitost. Identita by sice šla použít, ale nelíbí se mi zápis třeba $presenter->user->identity->getBooks();

Dokud jsem měl třídu Model jako service locator a všechna komunikace mezi presentery a modelem probíhala přes ní, tak jsem měl uživatele dva: $presenter->user a $presenter->model->user s tím, že ten druhý sloužil jako entita i jako implementace IRole a IResource.
Ale ten centrální service locator Model teď chci refaktorovat na jednotlivé service/fasády a nechci, aby každá z nich musela udržovat vlastní instanci User pro potřeby dynamické kontroly práv. A vlastně i službu Authorizator. (Stále jsem přesvědčený, že kontrola práv patří i do modelu, nejen presenterů).

bazo

ja v startup metode secured presentera vzdy priradim do premennej entitu usera a pracujem s nou v celej aplikacii.

nette usera pouzivam len pre overenie prihlasenia