Event-driven CMS - zalety i wady

Question

Próbuję zidentyfikować niektóre z zalet i wad posiadania CMS, który jest sterowany zdarzeniami.

Kierowanie zdarzeniami nie jest niczym niezwykłym. Widać to w wielu językach skryptowych, takich jak Actionscript, javascript, jquery, które angażują klienta. Co powiesz na CMS, w którym zdarzenia i ich odpowiedzi pojawiają się na serwerze. Jakie wady i zalety mogą mieć takie podejście i jakie są inne podejścia, które ludzie mogą preferować bardziej.

P.S. Zwróć uwagę, że używam Actionscript, JQ i JS jako przykładu. Zdajesz sobie sprawę, że kiedy mówisz o CMS w ten sposób, zdarzenia i ich reakcje są po stronie serwera.

Edit: Widzę wiele osób mówi, że to nie ma sensu do korzystania zdarzeniami jak nie dostać tego, co to jest. Jednym z systemów CMS, które już używają tego podejścia jest Drupal, więc zaufaj mi, że to istniejący sposób, nie wyciągam pomysłów z mojego A. To po prostu oznacza "elementy wewnętrzne" CMS (wszystkie rzeczy po stronie serwera) są sterowane zdarzeniami. Rdzeń robi swoje rzeczy I definiuje zdarzenia. Wtyczki mogą odpowiadać na te zdarzenia, aby dodać własną logikę. Przykładem może być Actionscript, ponieważ strona klienta jest tam, gdzie ta koncepcja jest najbardziej znana, ale może być również po stronie serwera, może nie tak istotna dla zwykłych aplikacji i tak nie jest znana. Ale ma sens coś bardziej złożonego, jak CMS, gdzie inni programiści chcą dodawać własne wtyczki lub nawet zmieniać wbudowaną logikę CMS.

Answer 1

Co dokładnie masz na myśli przez "napędzane zdarzeniami"? Czy oznacza to, że klienci mogą oglądać treści i będą powiadamiani, kiedy zostaną zaktualizowane?

Jeśli tak, to jest to naprawdę świetny pomysł, ale wdrożenie jest ambitne. Wyraźną wadą jest to, że istnieje mnóstwo rzeczy, które mogą pójść nie tak, podczas gdy model oparty na zapytaniach jest znacznie prostszy, a przez to bardziej solidny.

Answer 2

Czy na pewno "zdarzenie sterowane" jest właściwym określeniem?

Myślę, że to, o czym mówisz, to infrastruktura wtyczki, która pozwala wtyczkom działać, gdy zdarzenie ma miejsce (uruchamiany jest hak).

To, co wiem, to "zdarzenie sterowane zdarzeniami", gdy aplikacje desktop przechowują zdarzenia w elementach interfejsu użytkownika, tak jak JavaScript może zrobić dla elementów HTML. Aplikacje na komputery są zbudowane w ten właśnie sposób. Tego nigdy nie można osiągnąć w PHP opartym na sieci Web, ponieważ jest całkowicie zorientowany na żądanie.

W każdym razie, widzę, co masz teraz na myśli. Istnieją CMSy i frameworki, które mają to do pewnego stopnia - na przykład Wordpress i Dokuwiki.

• W Wordpress te zdarzenia są nazywane akcjami. Możesz zobaczyć pełną listę w the Wordpress Plugin API.

• W DokuWiki, są one rzeczywiście zwane wydarzenia: DokuWiki's event system

Ponadto:

Próbuję zidentyfikować niektóre z zalet i wad o CMS, który jest wydarzeniem napędzany.

Zalety są oczywiste: o wiele łatwiej jest podłączyć się do systemu bez konieczności włamania do rdzenia. Staje się możliwe pisanie prawdziwych wtyczek.

Jedną z dużych zalet jest to, że system ma tendencję do wolniejszego działania w dłuższej perspektywie, im więcej jest haków, a więcej wtyczek jest zarejestrowanych w hakach. Widziałem ogromną operację konserwacyjną portalu - usunięcie kilkuset węzłów Drupala - wykonuję godzin na ultraszybkim serwerze produkcyjnym, głównie z powodu systemu hakowania.