Czesc wszystkim.


Mam 2 pytanai dotyczace spojnosci kodu i parametrow:

Otoz pisze klase do obslugi logow, ktora ma pozwalac na zapisywanie ich w plikach, bazie danych czy przesylanie do sysloga, w zaleznosci od wybranego poziomu logowania. Dzieki temu bledy moga trafic do innego miejsca niz ostrzezenia. W oby przypadkach moze to byc rozna baza danych, badz rozne pliki.

Tak wiec, pierwsze klaska w ktorej bede zapisywal logi do plikow musi wiedziec do jakiego pliku je zapisac, natomiast klasa logujaca zdarzenia w bazie musi wiedziec w jakiej bazie i jakiej tabeli sa przechowywane. To sprawia ze parametry konfiguracyjne beda nie tylko rozne, ale roznic bedzie sie takze ich ilosc. (plik - nazwa pliku; DB - baza, tabela). Chcialem aby w obu przypadkach, opcje byly przekazywane w formie tablicy do konstruktora:

[PHP] pobierz, plaintext 
function __construct($config = []);
[PHP] pobierz, plaintext 

I nastepnie szukac w $config['filename'], $config['db'], $config['table'] itp.

Wywolanie konstruktora byloby wowczas takie samo. Pytanie nr 1 brzmi: czy to dobre podejscie?
W sytuacji gdyby np sciezka do pliku nie zostala podana, chcialbym rzucic wyjatek mowiacy o tym, ze do konstruktora zostala przekazana nieprawidlowa konfiguracja.

Tutaj jednak rodzi sie drugie pytanie: Otoz wyobrazam sobie w przyszlosci jakis panel administracyjny w ktorym bedzie mozna wybrac ze system ma logowac bledy do pliku lub bazy i po wybraniu odpowiedniej opcji, uzytkownik dostanie odpowiednie pola do wyboru. Skad aplikacja ma wiedziec ze 1 konstruktor czeka na $config['filename'] a drugi na $config['db'] i $config['table'] ?

Ostatnie pytanie brzmi: Jak najlepiej zapewnic takiej klasie dostep do bazy danych? Powinna ona w parametrze $config['db'] dostac DSNa i nawiazac polaczenie do bazy? A moze skorzystac z tego samego polaczenia co cala aplikacja? Co jesli to beda 2 rozne bazy? Moze powinien pierw sprawdzac czy w $config['db'] jest obiekt klasy Database i wtedy operowac na nim, a jesli nie, sprawdzic inna opcje - przykladowo $config['dsn'] i nawiazac nowe polaczenie?

Podstawowe pytanie. Monolog Ci nie wystarczy? Bo w sumie robi dokładnie to czego potrzebujesz.

Wole napisac cos swojego, poza tym te same pytania pojawia sie pewnie takze pozniej, przy implementowaniu innych funkcjonalnosci.

Ja nie neguję pisania swoich rozwiązań ale czy warto w tym przypadku akurat zawracać sobie gitarę robieniem czegoś co jest i działa świetnie a do tego ma multum opcji konfiguracji?

Np. rozdzielenie na wiele BD sprowadza się do dodania 2 lub więcej wrapperów i określenie miejsca wraz z poziomem błędu jaki ma łapać.

Byc moze masz racje, ale jak juz nie raz pisalem, takie podejscie ma tez swoj aspekt edukacyjny. A nawet gdy wezme gotowego loggera, to taki sam alb o zblizony problem moze pojawic sie rowniez na pozniejszym etapie. Chcialbym pominac aspekt oplacalnosci i skupic sie na konkretnym przedstawionym problemie. nawet jesli zdecyduje sie skorzystac z gotowca, chetnie poznam rozwiazanie.

No dobra... No to tak, Piszesz sobie wpierw klasy Wrappera czyli klasę per metodę zapisu np. file log, syslog, DB z interface np. LogWrapperInterface.
Potem piszesz sobie główną klasę do której za pomocą metody np. addWrapper() będziesz dodawał obiekty klasy tworząc tym samym zbiór kolekcji. (dla każego wrappera podajesz oddzielnie konfiguracje)

Potem wywołując metodę CustomLogger->info('aonsfdasdf');
lecisz po każdym elemencie kolekcji (wrapperach) i odpalasz na nich metodę info() odpowiednio zapisując gdzie trzeba.

Tak mega skrótowo.

Dzieki, ale to akurat wiedzialem. Moje pytania byly zupelnie inne

@q.michal musisz wziasc poprawke na starych ludzi. W pewnym wieku niedoslysza i niedowidza (wiem z wlasnego doswiadczenia ). Takze dobrze, ze jestes wyrozumialy dla Pytona. Za ktoryms razem zalapie

edit down:
@Pyton co tam piszesz? Daj wieksza czcionke... troche niedowidze...

1. array jest ok.
2. Z dokumentacji. Skoro ktoś ma sam sobie podawać dane to musisz mu pokazać co ma podać. Sam wrapper powinien sobie jakoś zwalidować config.
3. Przekazujesz obiekt PDO (tudzież inny wrapper i pod niego piszesz handler)

Możesz też stworzyć klasy np. DbLoggerConfig, FileLoggerConfig itd. i tam podawać w konstruktorze odpowiednie informacji.

@nospor wredna bestia

2. Co w sytuacji, kiedy budujac panel admina bede chcial, aby uzytkownik mogl podac wszystkie dane? Aby odpowiednie input boxy mu sie pojawily po wybraniu pozycji z drop-listy? Jesli dobrze rozumiem, trzeba bedzie wszystko oskryptowac? Moglbym zaimplementowac metode customLogger->listWrappers(); ktora zwroci liste wszystkich obslugiwanych backendow i dodac wszystkie elementy tablicy do drop-listy, ale nie bede mial niezbednych parametrow.

Z jednej strony mozna by zrobic switcha i dopisac odpowiednie parametry (wg. dokumentacji), z 2 strony trzeba bedzie to robic za kazdym razem kiedy dodany zostanie nowy backend.

Jak często będziesz dodawał nowe wrappery Aż tak dużo danych nie ma. Zawsze możesz per Wrapper dodać metodę getParamList() która zwróci Ci nazwę parametru, type, ew. jeszcze przykład. No i tyle. Potem foreach sobie lecisz po liście wrapperów, odpalasz metodkę i wrzucasz odpowiednie pola.

Dzieki za rozwianie watpliwosci.