This document discusses various ways to customize Symfony2 applications, including:
1. Customizing the dependency injection container by modifying services, parameters, and adding compiler passes.
2. Leveraging events by creating custom event classes, dispatching events, and adding event listeners.
3. Extending and overriding bundles by creating child bundles, overriding controllers, routing, and templates.
4. Using external tools like Composer, React, PHP Process Manager, and Varnish to enhance applications.
Developer Data Modeling Mistakes: From Postgres to NoSQL
Symfony2 Customization Ways
1. Symfony2 your way
by Rafał Wrzeszcz, 2014
rafal.wrzeszcz@wrzasq.pl
http://wrzasq.pl/
http://chilldev.pl/
https://github.com/rafalwrzeszcz
https://linkedin.com/in/rafalwrzeszcz
14. Own tags handler
class MyPass implements CompilerPassInterface
{
public function process(ContainerBuilder $container)
{
$class = $container->getParameter('my.datasource.class');
foreach ($container->findTaggedServiceIds('my.datasource') as $id => $tags) {
foreach ($tags as $tag) {
$definition = $container->register($tag['alias'], $class);
$definition->setArguments([
new Reference($id),
$tag['prefix']
]);
}
}
}
}
15. Most important pre-defined tags
● twig.extension/templating.helper – registering templating helpers,
● security.voter – custom security access logic,
● monolog.logger – marking specific channels for the logger,
● kernel.event_listener/kernel.event_subscriber – subscribing to
events,
● data_collector – web profiler data collector.
More on http://symfony.com/doc/current/reference/dic_tags.html.
17. Events
● move your non-core features to event handlers,
● keep core logic thin and simple,
● provide before and after events.
18. Custom event object
class MyLibFormEvent extends Event
{
const FORM_SUBMITTED = 'my_lib.form.event.submitted';
const FORM_HANDLED = 'my_lib.form.event.handled';
// properties
public function __construct(/* custom event params */)
{
// assign properties
}
// getters and setters
}
19. Dispatching the event
$eventDispatcher = $di->get('event_dispatcher');
$eventDispatcher->dispatch(
MyLibFormEvent::FORM_SUBMITTED,
new MyLibFormEvent(/* custom data */)
);
// process form
$eventDispatcher->dispatch(
MyLibFormEvent::FORM_HANDLED,
new MyLibFormEvent(/* custom data */)
);
21. Symfony kernel events
● kernel.requestnew request is being dispatched,
● kernel.responseresponse is generated by request handler (like controller),
● kernel.finish_requestfired after request is handled – regardless of operation
status,
● kernel.terminateresponse is already sent – we can perform some heavy tasks that
won’t afect page load,
● kernel.exceptionunhandled exception occured during request handling.
22. DI tag event_listener
<service id="my.lib.response_listener" class="%my.lib.response_listener.class%">
<tag name="kernel.event_listener" event="kernel.response" method="onKernelResponse"/>
</service>
25. Pointcut
class MySecurityPointcut implements PointcutInterface
{
public function matchesClass(ReflectionClass $class)
{
return $class->implementsInterface('MyDataAdapterInterface');
}
public function matchesMethod(ReflectionMethod $method)
{
return $method->getName() == 'read';
}
}
26. Interceptor
class MySecurityInterceptor implements MethodInterceptorInterface
{
public function intercept(MethodInvocation $invocation)
{
if (/* security checks */) {
// you can modify $invocation->arguments array
$result = $invocation->proceed();
// you can post-process results
return $result;
} else {
throw new SecurityException('Unauthorized access attempt.');
}
}
}
Ale przedefiniowywanie usług trąci nieco hackowaniem - możemy w ten sposób naruszyć pewien kontrakt. Może się okazać, że z czasem usługa, którą nadpisujemyu zacznie przyjmować dodatkowe parametry. Istnieje bardziej subtelny sposób, który sprowadza się mniej więcej do tego samego - podmienienia klasy, z której będzie instancjowana usługa - lecz przy pomocy samych parametrów, tak, aby nie ryzykować ingerencji w jakiekolwiek interakcje z usługą (takie jak wywołania metod).
Ten sposob to parametr z sufiksem ".class". Jest to konwencja, dzięki której właśnie mamy możliwość zawsze podmiany implementacji usługi na naszą (oczywiście musi ona być kompatybilna).
Jak to działa? Po prostu definiując nasze usługi tworzymy jeden dodatkowy parametr dla każdej z nich z sufiksem ".class" (także dobrze jest o tym pamiętać rónież nazywając parametry - tak, aby unikać nazw parametrów z tym sufiksem). Parametr ten przechowuje nazwę klasy wykorzystywanej przez usługę i umożliwia jej łatwą zmianę (wystarczy nadpisać jego wartość, nie trzeba nadpisywać całej usługi).
W taki sposób (z użyciem parametru klasy) zdefiniowane są wszystkie usługi samego Symfony2, a także większości popularnych (i tych mniej popularnych też) bundli. Generalnie praktycznie nic nas nie kosztuje dodanie takiego parametru do naszych usług, a potrafi to nieraz uratować tyłek, szczególnie, jeśli tworzymy jakiś bundle ogólnego przeznaczenia, z którego mieliby korzystać inni.
Kolejną rzeczą, którą możemy modyfikować względem bazowego bundle’a jest routing. Przy czym aby nasze przesłanianie było możliwe trzeba skorzystać ze specjalnej notacji, która oznacza odniesienie do zasobów względem danego bundle’a. W ten sposób możemy przesłonić dany statyczny plik tworząc plik o takiej samej nazwie i ścieżce.
Bardzo podobnie ma się sprawa z przesłanianiem szablonów. Właściwie dosłownie tak samo – aby przesłonić szablon widoku tworzymy plik o takiej samej nazwie i takiej samej ścieżce w naszym bundlu.
Ale, w przypadku szablonów należy pamiętać o jednej istotnej rzeczy, a mianowicie różnice pomiędzy przesłanianiem szablonów, a ich rozszerzaniem. Jest to o tyle problematyczne, że angielskojęzyczne nazwy konstrukcji odpowiedzialnych za te poszczególne cechy systemu szablonów są zbieżne z nomenklaturą w programowaniu obiektowym, ale ich działanie jest odmienne, żeby nawet nie powiedzieć odwrotne.
Przesłaniając szablon całkowicie przesłaniamy go w systemie, nie ma żadnej możliwości dostępu do niego, nasz szablon musi go w całości zastąpić
Korzystając z mechanizmu rozszerzania definiujemy logiczny ciąg zagnieżdżania szablonów – w tym przypadku nasz widok zostanie osadzony w innym, konkretnie w głównym layoucie aplikacji. Użycie `parent()` w kodzie odnosi się właśnie do tego zagnieżdżenia, nie do przsłoniętego widoku z bundle’a.
W przypadku szablonów mamy też możliwość przesłaniania szablonów w jeszcze jeden sposób – przez zasoby samej aplikacji.
Zasoby aplikacji mają najwyższy priorytet, lecz warto zwrócić uwagę na inną budowę ścieżki.
I w końcu ostatnia część, a mianowicie zewnętrzne usługi i narzędzia. Nie samym Symfony człowiek żyje. Na szczęście społeczność Symfony dobrze o tym wie, framework ten jest bardzo otwarty i “przyjazny” w kwestii integracji z zewnętrznymi usługami, API, czy narzędziami.
W bardzo wielu frameworkach istnieje podejście tworzenia wszystkiego samemu, podczas gdy w Symfony podejście jest zazwyczaj odwrotne – jeśli istnieje już do czegoś rowzwiązanie to w Symfony2 często znajdziemy integrację z takim rozwiązaniem.
Tworząc projekt w Symfony praktycznie nie obejdziemy się bez Composera (nie jestem jego wielbicielem, ale jest to obecnie praktycznie de facto standard, więc nie ma co wynajdywać koła na nowo).
Jedną z większych, moim zdaniem, ułomności w Composerze jest sposób podpinania się z własną implementacją pod cokolwiek, no ale nie będę się rozwodził o moich wewnętrznych odczuciach…
W Composerze możemy podpiąć się pod zdarzenia (ich listę można znaleźć w specyfikacji na stronie). Sensio (twórcy Symfony) udostępniają kilka gotowych skryptów, które pozwalają zautomatyzować cykl pracy z aplikacją.
Ale Composer daje nam pewną bardzo potężną broń. Chyba najbrzydszy z jakichkolwiek dziś przeze mnie tutaj prezentowanych hacków. Jeśli myśleliście, że przedefiniowywanie definicji usług w DIC było złe, to spójrzcie na to.<klik>
Otóż możemy całkiem przesłonić klasy dowolnej ładowanej przez nas biblioteki naszymi własnymi jeśli tylko nadpiszemy autoloader generowany przez Composera.
Ale jest jeden warunek – musimy skorzystać z autoloadera typu classmap (niezależnie od tego, że Composer i tak generuje dla nas class-mapę, chodzi o hierarchię loaderów, class-mapa jako najszybsza i generowana docelowo, jest pierwszym miejscem, gdzie wygenerowany autoloader szuka klasy).
Kolejnym ciekawym i niezmiernie obiecującym projektem jest React. Implementuje on model przetwarzania request-response znany z wielu innych platform, takich jak chociażby Node.js.
Co to ma wspólnego z Symfony?
Oczywiście możemy, jako funkcję obsługującą żądanie zaimplementować bootstrapping naszej aplikacji Symfony, ale jest jeszcz lepiej – coś takiego już istnieje.
Kożyści są bardzo duże, przede wszystkim odchodzi konieczność każdorazowego bootstrapowania aplikacji, która nawet przy bardzo zoptymalizowanych projektach wymaga zazwyczaj dużo operacji wejścia/wyjścia (chociażby wczytywanie plików), co jest nieraz największym obciążeniem.
Możemy również wykorzystać nową architekturę i wyeliminować niektóre inne zależności, na przykład niektórych rzeczy nie trzeba trzymać w cache’u, czy sesji, gdyż można je trzymać bezpośrednio w pamięci procesu.
Nie ma niestety róży bez kolców. Jest to kompletna zmiana podejścia w przypadku PHP, pamiętajmy, że w normalnym trybie skrypty PHP są zawsze uruchamiane w odrębnym środowisku. W tym przypadku musimy pamiętać, że nasz skrypt działa nieprzerwanie, każde kolejne zapytanie operuje w tym samym środowisku, a więc musimy być świadomi, że na przykład ta sama instancja naszego obiektu będzie wykorzystana podobnie, więc inicjując obiekty musimy być pewni kiedy się ona wykonuje.