Witajcie,

Nie mam potężnego doświadczenia w fw i w związku z tym zainteresowało mnie zagadnienie event listenerów.

Trochę sobie o nich poczytałem, ale ciężko mi sobie wyobrazić jakieś fajne sytuacje, gdzie można by je wykorzystać(oprócz tego opisanego w dokumentacji).

1) Dacie jakieś przykłady?
2) Czy m.in. można nimi zastępować mysql'owe triggery(wyzwalacze) i czy to jest sensowne(czy takie jest m.in. przeznaczenie event listenerów)?
3) Zamiast bawić się w mysql'owe triggery może lepiej krok po kroku usuwać wpisy w ten sposób?

[PHP] pobierz, plaintext 
$em->remove($obiekt1);
$em->remove($obiekt2);
$em->remove($obiekt3);
$em->flush();
[PHP] pobierz, plaintext 

1. Pytasz o zdarzenia w kontekście Symfony czy Doctrine?
2. Można, ale raczej nie ma to większego sensu, chyba że w takim wyzwalaczu potrzebowałbyś mieć dostęp do danych/narzędzi aplikacji, a nie surowej bazy danych.
3. Bazy danych obsługują, a Doctrine wspiera kaskadowe usuwanie danych, więc nie ma potrzeby dla tego typu wynalazków.

ORM ma przejac wszystkie zadania na bazach wiec lepszym pomyslem jest przeniesienie triggerow na ORMowe klasy, bo kiedy baza czegos nie może to ORM to ogarnie, nie ma tez problemow z migracjami na inne bazy danych bo w 99% wystarczy tylko zmienić providera.

@skowron-line: Troszkę się pośpieszyłeś z tym stwierdzeniem, że ORM ma przejąć wszystkie zadania (nie ma) oraz że zmiana bazy danych ogranicza się do zmiany sterownika - chyba, że mówimy o strasznie trywialnych aplikacjach.

@skowron-line:
Ja akurat jestem zdania, że wszystko co się da lepiej robić po stronie bazy danych (triggerami czy chociażby usuwaniem kaskadowym). Zyskasz przede wszystkim na wydajności, a przede wszystkim na spójności danych. Ingerując w zawartość bazy z poziomu samej bazy danych (pomijając aplikację) masz pewność, że operacje powiązane również zostaną wykonane. Oczywiście są sytuacje, gdy nie będziesz w stanie wykonać czegoś po stronie bazy (z technicznego punktu widzenia) i będziesz zmuszony zrobić to po stronie aplikacji, ale co się da dawałbym po stronie bazy.

@Crozin
1) Kurde, a ja myślałem, że te zagadnienie dotyczy tak samo symfony jak i doctrine. A więc jeśli chodzi o odpowiedź to mogą być w kontekscie symfony i doctrine osobno

Wszystkie odpowiedzi były przydatne. Póki co to część przeniosę do ORM'a i tam gdzie będzie się dało użyje usuwania kaskadowego. Na wydajności nie specjalnie mi zależy bo i tak projekt zawsze będzie działać na localu, aczkolwiek na przyszłość chciałem wiedzieć co i jak. Póki co najważniejsze to dobrze poznać symfony 2

1. Oba narzędzia wykorzystują na dobrą sprawę ten sam mechanizm, ale - co oczywiste - do innych celów. Przykładowo w Doctrine możesz wykorzystać zdarzenia w celu:
- zmodyfikowania obiektów tuż przed ich zapisem do bazy (np. w celu dodania daty i adresu IP osoby modyfikującej dany obiekt),
- zmodyfikowania zapytań SELECT DQL-a tak, by ignorowały obiekty oznaczone jako usunięte, a zapytania DELETE zamienić na UPDATE (tzw. softDeleteable),
- zmodyfikowania struktury mapowań Doctrine'a.
W Symfony, z racji tego że jest to znacznie obszerniejsza biblioteka, zdarzeń można tego wykorzystać już do setek rzeczy, np.:
- wykonania jakiejś wspólnej akcji dla wszystkich kontrolerów z danego bundle'a,
- wysłaniu maila do autora jakiegoś obiektu domeny po jego usunięciu,
- aktywacji użytkownika, który rejestruje się jakąś zaufaną metodą (np. poprzez OpenID),
- zablokowaniu dostępu do danych akcji danym użytkownikom,
- ...tutaj można by wymieniać bez końca.

No dobra moze wszystkich było nadużyciem, chodzi mi głównie o triggery.

Poniekąd mogę dodać, że dobrą praktyką jest przenoszenie logiki biznesowej do event listenerów: http://stackoverflow.com/questions/1915472...ony-application
Gdy z punktu widzenia biznesu np. przy tworzeniu nowego użytkownika powinno się wysyłać email informacyjny, powiadomić innych użytkowników itp.. tego typu rzeczy dobrze trzymać w event listenerach.