lms
lms copied to clipboard
problemy z systemem pluginów
@chilek tu możemy omówić problemy z systemem pluginów
- Biblioteki porzucone/osierocone: phine/exception 1.0.0 A PHP library for improving the use of exceptions. phine/observer 2.0.0 A PHP library that implements the observer pattern.
- phone/observer nie pozwala na rekursywne wywoływanie ExecuteHook().
ad 1. tak mogło się stać z każdą zależnością, jeśli nie ma w niej bugów to nie jest źle; ad 2. to akurat dobrze, plugin mógłby zapetlić wykonywanie hooków, przydałby się jakiś przykład kiedy taka funkcjonalność jest niezbędna.
Raczj bym tego nie ruszał.
ad 2. to akurat dobrze, plugin mógłby zapetlić wykonywanie hooków, przydałby się jakiś przykład kiedy taka funkcjonalność jest niezbędna.
- Podpinamy się pod: https://github.com/lmsgit/lms/blob/master/lib/LMSManagers/LMSCashManager.php#L405
- W obsłudze 1 robimy powiadomienie mailowe w oparciu o LMS::SendMail().
- W SendMail() mamy: https://github.com/lmsgit/lms/blob/master/lib/LMS.class.php#L2015 (chcemy mieć możliwość wpłynięcia na treść listu przed wysyłką każdego listu).
Dzięki za przykład. Nie rozumiem jednak dlaczego SendMail nie mógłby dostać wszystkiego co powinien już podczas wywoływania tej metody. Mam wrażenie że hooki trochę wymknęły się spod kontroli i mogą być wszędzie...
Pewnie ten hook będzie musiał tam już zostać na jakiś czas bo ktoś z tego korzysta, ale trzeba by przemyśleć czy pozwalać w przyszłości na takie coś.
Z perspektywy czasu widzę, że lepiej by było jakby hooki/eventy (czy jakkolwiek to nazwiemy) nie wpływały na wykonanie standardowej ścieżki programu tylko powodowały rozpoczęcie kolejnej po tym jak ta pierwsza się już zakończy. Wygląda to na sporo roboty ale może uda mi się coś takiego przygotować.
Dzięki za przykład. Nie rozumiem jednak dlaczego SendMail nie mógłby dostać wszystkiego co powinien już podczas wywoływania tej metody. Mam wrażenie że hooki trochę wymknęły się spod kontroli i mogą być wszędzie...
Stare hooki (nie wiem czy z tego kiedykolwiek korzystałeś) takich ograniczeń nie miały.
@maciejlew dorzucę jedną rzecz do tematu który jest ogólny:
3. krytyczny błąd w kodzie wtyczki jest w stanie unieruchomić całego LMS'a np. die();
w kodzie wtyczki. Zamiast zakończyć kod wtyczki sprawia że "website is down"
2\. phone/observer nie pozwala na rekursywne wywoływanie ExecuteHook().
Próba wywołania NotifyUsers w nowej wtyczce powoduje błąd phone/observer w funkcji SendSMS. Możliwości ominięcia tego jest kilka. Być może dobre było by dodanie do klasy LMS dodatkowej zmiennej i ustawienie ExecuteHook wewnątrz warunku if. Wówczas we wtyczkach można by wyłączać hooki kiedy powodują problem. Dalej niemożliwa będzie interakcja między wtyczkami ale możliwe będzie używanie bazowych funkcji LMS bez robienia kopii funkcji.
W pliku vendor/phine/observer/src/lib/Phine/Observer/Subject.php
wystarczy zakomentować fragment:
public function notifyObservers()
{
if ($this->updating) {
throw SubjectException::alreadyUpdating();
}
$this->resetInterrupt();
(blok z if ($this->updating)
.
Kod phine już od wielu lat nie jest od kilku lat utrzymywany przez autora i stanowi niezły balast.
Zrobiłem to przez dziedziczenie i własną wersję funkcji.(Wiem że przy aktualizacjach LMS może się to zemścić.) Konieczność modyfikacji żeby skorzystać z wtyczki, raczej kiepska propozycja. Będzie trzeba się przyglądnąć Phine w takim razie.
Będzie trzeba się przyglądnąć Phine w takim razie.
W jakim sensie? Moim zdaniem to już trup ;-)
Czy warto go ożywić?
@maciejlew jest jeszcze jedna drobna rzecz - brakuje w systemie pluginów miejsca gdzie można zdefiniować:
- kod wykonywany tylko raz przy instalacji wtyczki,
- kod wykonywany przy kliknięciu przycisku wyłącz,
- kod wykonywany przy kliknięciu przycisku włącz,
- kod uruchamiany przy permanentnym odinstalowaniu wtyczki,
Obecnie to jest rozsiane po instrukcjach, oddzielnych plikach SQL lub w ogóle nie ma. Może to nie stanowi, żadnej przeszkody w kodzie ale każda wtyczka nie była robiona na swoją modłę to: "fajnie by było gdyby to było".