Správné použití Nette s Kdyby\Events a různé akce

Ripper napsal(a):

Narazil jsem na Kdyby\Events a hrozně se mi to zalíbilo a chtěl bych to používat na většině akcích co se na webu dějí…

Děláš mi radost ;)

A přesně takhle bych to chtěl udělat například když si uživatel změní heslo. Ale jak na to správně? Původně jsem myslel že si prostě vytvořím třídu User která bude dědit od Nette\Object a tam si vložím různé funkce, například funkci changePassowrd a dále tam budu mít proměnou onPasswordChange a na ní napojím UserListener výše. Ale nevím zda je to takto správně a když jsem to zkoušel, tak to akci nezalogovalo.

Kdyby\Events fungují tak, že aby události fungovaly, musí třída být registrována v DI Containeru. Není tedy možné dělat události nad entitami (možné to je, ale není to moc sexy).

Správný postup tedy je, událost vytvořit v nějakém usermodelu.

class RegisteredUsers extends Nette\Object
{
	public $onChangePassword = array();

	public function changePassword(MyUser $user, $oldPassword, $newPassword)
	{
		try {
			$user->changePassword($oldPassword, $newPassword);
			$this->onChangePassword($user);
			$this->save($user);

			return TRUE;

		} catch (InvalidPasswordException $e) {
			return FALSE;
		}
	}

	// ...
}

class MyUser extends Nette\Object
{
	private $id;
	private $password;

	public function changePassword($oldPassword, $newPassword)
	{
		if ($this->password !== my_awesome_crypt_func($oldPassword)) {
			throw new InvalidPasswordException("Old password doesn't match");
		}

		$this->password = my_awesome_crypt_func($newPassword);
	}

}

Například takto :) Teď už stačí jen zaregistrovat třídu RegisteredUsers jako službu, doplnit chybějící metodu save a injekci databázového připojení přes konstruktor a valíš :)

Ahoj Filipe,

moc se mi to libi. Narazil jsem ale na problemy s dedenim. Pouzivam BaseRepository, ze ktere deni ostatni, napriklad CommentRepository. Asi takto:

class BaseRepository extends Nette\Object
{
	protected $mapper;

	public $onInsert = array();
	public $onUpdate = array();

	public function update(BaseObject $item)
	{
		$result = $this->mapper->update($item);
		$this->onUpdate($item);
		return $result;
	}


	public function insert(BaseObject $item)
	{
		$result = $this->mapper->insert($item);
		$this->onInsert($item);
		return $result;
	}
}

BaseObject je predchudce vsech mych zakladnich objektu (entit), napr. Commentu.
Pak mam CommentListener:

class UserListener extends Nette\Object implements Kdyby\Events\Subscriber
{
    public function getSubscribedEvents()
    {
        return array(
            'CommentRepository::onInsert' => 'commentInserted'
        );
    }

    public function commentInserted(Comment $comment)
    {
        //zpracovani
    }
}

Problem je, ze commentInserted se nikdy nezavola. V DebugBaru pred registrovanim CommentListeneru mam:

0x BaseRepository::onInsert
no system listeners

Po registrovani CommentListeneru stejne, jen pribyde:

0x CommentRepository::onInsert
Kdyby\Events\Subscriber

Pokud kod nepodedim, ale zapisu ho primo do CommentRepository, tak to taky funguje. Dekuji za radu.

@ProchazkaFilip díky!

1. je služba registována v DIC?
2. vidíš event v events debug panelu ?
3. co se vygenerovalo do system containeru? vložil se do property Event objekt?

Ahoj,

prosím o radu, případné nakopnutí:
Mám vytvořenu událost, která reaguje na vytvoření uživatele, jemuž bych pak chtěl poslat email, kde bude link na přihlášení/aktivaci nebo cokoli podobného. A tento link bych chtěl generovat. Email generuji z templatu.

Čili jaký bude lepší přístup? Zapomenout na můj EventListener a volat to na presenteru nebo nějak do EventListeneru dostat (asi) presenter a pomocí něj pak vygenerovat odkaz?

Případně je ještě nějaká jiná možnost, jak odkaz v template vygenerovat?

Osobně se mi moc nelíbí postup níže, protože modelu/fasádě předávám cosi navíc, než by potřebovala:
Presenter

<?php

...
$this->_users->save($user, $this);
...
?>

Model:

<?php
class Users extends \Sasule\Common\BaseModel {

    public $onUserCreated = array();

function save(User $_u, Presenter $_p){
	$this->save($_u);
	$this->onUserCreated($_u, $_p);
}

?>

Díky předem za případné rady :-)

Editoval sasule (1. 4. 2014 12:13)

No a nebo si nebudeš komplikovat život a vyžádáš si v konstruktoru toho listeneru třídu Application, z ní si sáhneš na presenter ->getPresenter() a link si vygeneruješ.

Případně já to ještě dělám tak, že šablonu presenteru „ukradnu“.

$template = clone $this->app->getPresenter()->getTemplate();

Ten clone je důležitý, aby jsi neupravoval šablonu pro presenter, ale měl vlastní kopii. Můžeš si pak nastavit soubor se šablonou a máš nakonfigurovaný objekt template, ve kterém už budou fungovat makra na odkazy.

Ahoj,

rád bych začal používat Kdyby/Events ale nějak se mi to nedaří rozjet.

• instal přes composer
• config.neon
• i v panelu to mám.

Níže je uveden nástřel servicy která se stará o blog, všechny závisloti jsou tam předány nechcí tady vypisovat kilometorvý kod. Ale nestane se nic.

servica

class BlogService extends \Nette\Object {


    public $onInsert = array();

    public function save($data) {

	$this->onInsert();
	//save do DB
    }

listener

class FooListener extends Nette\Object implements Kdyby\Events\Subscriber {

    public function getSubscribedEvents() {
	return array(
	    'Model\Services\BlogService::onInsert' => 'insert',
	);
    }

    public function insert() {
	dump("test");
    }

}

jiri.pudil napsal(a):

Obě třídy jsou zaregistrované v configu a listener má tag kdyby.subscriber?

bylo to tím tagem, omlouvám se, díky moc, už to jede

nyní

	FooListener:
		class: FooListener
		tags: [kdyby.subscriber]

Jestli tomu dobře rozumím, tak bych to viděl asi následovně:

<?php
class BlogService extends \Nette\Object {
    public onGetAll = array();

    public function getAll() {
	$this->onGetAll(...); //sem dáš, co předáš do listeneru.
	return $this->blogReposiotry->findAll();
    }

?>

@batko: koukni na kdyby/aop, treba to vyresi tvuj problem. ale nezneuzivej to ;)

tak to bych řek že je neštastné řešení. Co takhle si prostě udělat před samotným voláním mazání select na zjištění kolik tam čeho je a zda to jde smazat a pak klasicky buď udělat delete a nebo poslat flash zprávičku.

No ale používat na to eventy mi taky nepřipadá zas uplně ok ne?

Mně event + výjimka připadá nejrozumnější, ale udělej to tak jak to vyhovuje tobě a tvému týmu. Jde o to, aby byl kód dobře srozumitelný a spravovatelný, ne aby to bylo správně.

akadlec: Udělat kontrolu před samotným smazáním a pak kdyžtak smazat, je samozřejmě nejsnazší. Ale je tam už ten problém, že mazání města řeší něco co nemá… Nemluvě o tom, že v budoucnu bude moci být město i další objekty v systému a volat třeba 10 různých „tabulek“ z jednoho místa aby kontrolovali, zda to jde smazat, mi nepřijde příliš košér. A pokud pak použiju jen modul pro města, tak to nepůjde, protože to budu muset zase smazat…

matej21: vyjimka se mi prave taky moc nelibi, je to „ugly“. To s tím resultem zni zajímave, muzes to nejak rozvest? Příliš nechápu… A píšeš „když už použít eventy“, tak se ti to taky příliš nelíbí asi, jak ybs to řešil tedy ty?

Editoval Jiří Nápravník (8. 4. 2014 13:34)

@Jiří Nápravník: Nebylo by lepší nejprve se pokusit smazat, a až potom volat onErrorEvent?

@matej21: Ten subscriber by vytvářel odpovědi pro flashMessage nebo by se sestavovali až v presenteru?

Editoval jenicek (8. 4. 2014 14:19)

@Jiří Nápravník: No nevim to by pak měli řešit ty vychytaný logy co řešíme jinde.

Mazat FK by ti neměl nikdo jinak jsou k ničemu, pokud tedy nepoužívaš MyISAM.

Jak využiješ ten subscriber následně?

EDIT: měl by se vůbec zobrazit button na smazání, když ta akce není povolená?

Editoval jenicek (8. 4. 2014 15:50)

jenicek napsal(a):
EDIT: měl by se vůbec zobrazit button na smazání, když ta akce není povolená?

Neměl, ale 1. neni to prilis rozumne resitelne. Muselo by se jedine v databazi ukladat, kolik ma uziti to mesto a kdyz bude nula tak button vykreslit. Nicmene i tak je tam porad ten problem, ze nekdo muze manipulovat z adresou a da to smazat, takze se to sejne musi resit i na urovni kde se to samotne mazani provadi. Taky by na to šli teoreticky udělat eventy, když se přidá uživatel, zavolá se event, který aktualizuje ten counter uziti. Ale tam je pak zase ten nedostatek, že nepůjde vypsat: TOhle město je přiřazeno u 2 uživatelů a čtyř podniků.

akadlec: tak nemusi byt mimo manager. ale dává mi to smysl a je to doržování Single responsibility. Každá třída odpovídá za své. Může to být v jednom subscriberu (v případě shopu to tady asi i dává smysl). Ale třeba u toho mojeho města bude lepší udělat subscriber samostatný v nějakým tom UserModule, a pak třeba další, který bude checkovat jestli není přiřazen třeba u podniku, tak bude v nějakém CompanyModule

@Jiří Nápravník: Ok, myslel jsem nevytvářet button submit a nenavazovat na něj submit, nebo ho nechat disable, pak by to bylo řešitelné i u podvrženého url, ne?

@Jiří Nápravník: Ok už chápu, ja na tohle hlídání používám mazací formulář z CD-collection.

Editoval jenicek (8. 4. 2014 16:55)

Hele pánové a jak pak vyřešit flash message? V presenteru/komponentě si zavolám $manager->delete($entity) kde se provede zmíněná kontrola zda je to ok nebo ne, ale co pak dělat když to ok není? Zmíněná výjimka byla označena jako nevhodná, takže co?

@akadlec: K těm zprávičkám, už jsem to zmínil, nemohl by se o to starat ten Subscriber?

@Filip Procházka: Ten validaton objekt by mohl být service, tedy předán z neonu?

Editoval jenicek (8. 4. 2014 19:00)

Filip Procházka napsal(a):

A proč jsi nezaložil vlastní téma? :)

Sem se to celkem hodí a je to takové „support vlákno“ Kdyby\Events na foru:-)

Memyslís že se moc spoléháš na to že budeš mít tabulky v databázi? Nebo že budeš mít kód na hostingu? Tohle je pěkně absurdní obava :)

Přidat si tam vzdálený klíč je výborný nápad který bude fungovat jako poslední záchrana kdybys měl chybu v aplikaci, tak aby si databáze udržela aspoň trochu konzistentní data.

já jsem trochu paranoik no:-D ten cizi klic tam bude, protoze to jede na doctrine, ale furt si rikam, co kdyz prijde nejaky novy matlal, ktery zacne hrabat primo v databazi, ale ok nebudu paranoidni:-)

@jenicek neon ne, videl bych to na nově vytvoreny objekt pres new, ktery pošleš do subscriberu a vytáhneš si co to vratilo.

Sem se to celkem hodí a je to takové „support vlákno“ Kdyby\Events na foru:-)

Nemám rád support vlákna, v momentě kdy mají víc než dvě stránky je v tom pak bordel ;)

akadlec napsal(a):

@Filip Procházka: nn nemyslel sem vyhazovat výjimky z eventů ale přímo z manageru

Tak to pak jo, na tom není vůbec nic špatného. Já to taky tak dělám.

Samozřejmě :)

Rozhodně špatně, to nechceš. Ale co by šlo tak třeba tohle;

use Nette\Reflection\ClassType;

trait RenderableException
{
	public $count;
	public $parameters;
	public $domain = 'front';

	public function renderMessage(Kdyby\Translation\Translator $translator)
	{
		$message = ClassType::from($this)->getShortName() . '.' . $this->code;
		return $this->translator->translate($message, $this->count, $this->parameters, $this->domain);
	}
}

Nadefinuješ si výjimku

class CityRemovalException extends \RuntimeException
{
	const RELATION_RESTRICTION = 1;
	const LOCKED = 2;
	// ...

	use RenderableException;

	public function __construct($message, $code = 0, \Exception $previous = NULL)
	{
		parent::__construct($message, $code, $previous);
		$this->domain = 'city';
	}

	public static function relationRestriction(City $city)
	{
		return new static("Some relation is bound to " . $city->name . " and it cannot be deleted", self::RELATION_RESTRICTION);
	}

	// ...
}

vyhodíš

public function delete($city)
{
	if ($this->isReferenced($city)) {
		throw CityRemovalException::relationRestriction($city);
	}
}

chytneš a informuješ

try {
	$cityManager->remove($city);
	$this->flashMessage("ok");

} catch (CityRemovalException $e) {
	$this->flashMessage($e->renderMessage($this->getTranslator()));
}

Je to jenom koncept, musíš si to doladit :)