Aplikacje PHP - Pluginy Opcje

[Vengeance]

Witajcie,

Były już długie dyskusje o MVC, jeszcze dłuższe o budowie jądra...
Proponuje by rozpocząc dyskusje na temat, jak w naszej aplikacji umożliwić programiście piasnie dowolnych rozszerzeń. Chodzi mi o Pluginy.

Niektóre skrypty (phpBB) rozwiązują to na zasadzie zwykłej edycji kodu,
inne (WordPress) udostępniają specjalne API. Jak Wy widzicie budowe takiego systemu?

Powiesz szczerze, że nigdy nad takim czymś nie myślałem i nie robiłem nic w tym rodzaju więc w pierwszym poscie nie opisze swojego sposobu, bo go po prostu nie mam. Licze na Waszą inwencję i na to iż temat się przyjmie :]

Czyli podsumowując:
Jak stworzyć dobre API dla Pluginów.

[gamecreator]

Najpierw trzeba by jedną rzecz doprecyzować:
Są wtyczki [plugins] i są rozszerzenia [extensions]. Rozszerzenia to rzecz trochę bardziej ogólna, bo pozwalają na różne sposoby rozszerzać kod główny: np. dodając nowe inlcudy, dziedzicząc klasy interfejsów, dodając pliki językowe, szablony, filtry itp. Wtyczki to pewien podzbiór rozszerzeń.

Pluginy to inaczej wtyczki.
A jeśli jest wtyczka, musi też być i gniazdko (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Gniazdkiem są tzw. "hooki" [haki? miejsca zaczepienia?], czyli przewidziane wcześniej miejsca w kodzie głównym, do których można podczepiać kod wtyczek. Tak więc jeśli chcemy mieć możliwość dołączania pluginów w skrypcie, to musimy od począku pisać skrypt pod tym kątem i zostawiać "hooki" dla wywołań pluginów w miejscach, gdzie przewidujemy jakieś możliwości rozszerzania. Jeśli piszemy w taki sposób, możemy łatwo dodawać pluginy, które podczepią się do tych miejsc i coś zrobią. Jednak kod główny [core] pozostanie niezmieniony.

@faster: Dobrze kombinujesz. Co do Twoich wątpliwości, jak można rozszerzyć działanie kodu głównego bez zmieniania go, odpowiedź jest prosta: polimorfizm. Jeśli kod główny jest napisany w taki sposób, by działał na ogólnych interfejsach, zamiast na konkretnych obiektach, można bardzo łatwo rozszerzyć system o nowe klasy, które będą pasować do wywołań tego głównego kodu i będą nadpisywać [nie dosłownie, lecz poprzez polimorfizm] jego funkcje. Hooki w stylu before() i after() to najprostszy przykład czegoś takiego. Większe możliwości daje jednak dziedziczenie i nadpisywanie metod interfejsów w klasach pochodnych [w innych językach zwie się to "funkcje wirtualne" lub "polimorficzne"].

Jeśli jednak chcemy zmieniać każdą możliwą część systemu, to system od podstaw musi być w taki sposób napisany, by wszystkie jego składniki były pluginami, a główny kod zajmowałby się jedynie ich ładowaniem i rejestrowaniem powiązań między nimi. To jest już trudniejsze do zrobienia [choć nie niemożliwe (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ] i wymaga dobrego przemyślenia. Może też być mniej wydajne, bo praktycznie wszelkie wywołania musiałyby być dispatchowane w tablicy zarejestrowanych usług.

I tu przyszedł mi do głowy jeszcze jeden problem: baza danych. Często jest tak, że pluginy także potrzebują przechowywać jakieś informacje w bazie danych. O ile dodanie dodatkowej tabeli z kluczami obcymi jeszcze jakoś da się w miarę łatwo zrobić z poziomu pluginu, o tyle już np. modyfikacja struktury istniejących tabel może być trudna, o ile wogóle ma to jakiś sens. Wie ktoś może, jak rozwiązywane jest dodawanie pluginów z rozszerzaniem struktury bazy danych? Bo aktualnie istniejące bazy danych są raczej mało "polimorficzne" ;J

P.S.: @nasty, @Athlan: Ale robicie byki, kupcie sobie słowniki ;P