phiend2: reaktywacja Opcje

[hawk]

Jak niektórzy zapewne wiedzą, od dłuższego czasu pracuję nad phiendem 2. Niestety, po n-tym refactoringu i pisaniu wszystkiego od nowa jestem tym trochę zmęczony i raczej nie wydam tego kiedykolwiek o własnych siłach. Za to kod, który jest już napisany, bardzo mi się podoba i szkoda go marnować.

Więc poszukuję ludzi do współpracy.

Główne założenia:

• Napisany pod PHP5 i bardzo, bardzo obiektowo. Znacznie bardziej niż stary phiend. Co oznacza, że jest więcej klas, ale mniejszych.
• Oparty o interfejsy. Prawie wszystko można sobie wymienić na własnoręcznie napisaną klasę, jeżeli tylko ma taki sam interfejs.
• Rozwijany metodą małych kroczków. Zamiast wielkiego frameworka wg zasady wszystko-albo-nic, zbiór komponentów, z których większość jest opcjonalna albo może być używana niezależnie.

Poza samym MVC trzonem projektu są 3 kawałki kodu:

• phiend.autoloader: autoloader (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
• phiend.handle: zestaw klas do obsługi handles (trochę jak w WACT, służy do przekazywania referencji do obiektu bez tworzenia samego obiektu, kiedy nie jest jeszcze potrzebny)
• phiend.context: zbiór klas do obsługi całego request, response i sesji, trochę podobne do rozwiązania z Jav

Oprócz tego napisałem jeszcze bardzo fajny error handler, ale w odróżnieniu od phiend1 nie jest on częścią frameworka. Bo niby dlaczego MVC ma wymagać konkretnego error handlera?
Co do samego MVC, kilka słów:

• Front Controller (chociaż wymienialny; źródło jego konfiguracji: dowolne)
• Intercepting Filter (w postaci dekoratora na każdą akcję i w stylu javovym na cały request)
• żądanie przechodzi przez router, więc schemat URLi jest dowolny
• bez podziału na akcje i widoki, akcje można łączyć w łańcuch jak w phiendzie 1
• Akcje mają konfigurację; źródło tej konfiguracji: dowolne
• Ważne moduły (np. połączenie z DB, autoryzację) można podpiąć jako tzw. pluginy: system sam je skonfiguruje, uruchomi kiedy trzeba i zamknie na koniec

Kogo szukam?

• Ludzi, którzy sami potrafią zrozumieć kod, bo dokumentacji nie ma
• Ludzi, którzy lubią pisać dokumentację (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) , zwłaszcza tutoriale dla newbies, bo ja do tego nie mam serca i nigdy mi nie wychodzi
• Ludzi, którzy znają się na unit testach (dokładnie: SimpleTest), bo ja niestety nie i bardzo tego żałuję
• Ludzi, którzy chcą się skupić na jednym komponencie i dopracować go do końca
• Kogoś, kto mógłby w miarę postępu stworzyć nie przyprawiającą o mdłości stronę na SF
• Special request: Kogoś, kto np. zna Mojavi i chciałby zrobić w phiend2 jego emulator - IMHO wyjdzie szybciej, prościej i w ogóle lepiej (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

* więcej informacji w miarę wolnego czasu
** jeżeli temat tutaj nie pasuje, można śmiało przenosić

Ten post edytował hawk 30.05.2005, 20:02:11

[hawk]

Jak zapewne zauważyliście, długo mnie tutaj nie było i ten stan rzeczy nie ulegnie radykalnej zmianie. Po prostu przestało mnie to bawić. Programistą php nie jestem i nie będę, nie wiążę z tym przyszłości zawodowej, a w ramach spędzania wolnego czasu wolę wyżywać się na worku albo pić wódkę.

Projekt informatyczny, żeby był zauważony, musi żyć. Musi być aktywnie rozwijany. Trzeba reagować na zgłoszenia błędów i propozycje zmian. Trzeba robić ogólnie pojęty support. A tego akurat mi się całkowicie nie chce - w konkurencji spędzania wolnego czasu support plasuje się daleko, daleko za programowaniem. Natomiast bez supportu projekt staje się niszowy. Dla mnie niepotrzebny, bo ja i tak php w pracy używać nie będę.

Natomiast lubię projektować, i dlatego zostałem z rozgrzebanym kodem, który - sądząc po zainteresowaniu - jest dobrze pomyślany, ale którego sam nie doprowadzę do stanu używalności. Phiend2, jak pewnie zauważyliście, nie jest tak naprawdę frameworkiem. Jest zbiorem komponentów, na szczycie których jest co prawda framework MVC, ale nie jest on (dla mnie) najważniejszy. Teraz każdy ma własny framework, a ich porównywanie nie ma sensu. Natomiast mały komponent napisany w konkretnym celu może być znacznie łatwiej używany w różnych projektach.

Sytuacja jest więc taka: jest kilka mniej lub bardziej dokończonych komponentów i praktycznie martwa strona na SF. Na dole jest krótki opis tych komponentów. Jeżeli są zainteresowani, to chętnie przekażę je w dobre ręce, na zasadzie, że dalej jest to phiend, tylko autorów ma wielu. Na SF jest CVS, na którym można to rozwijać. Jest forum, jest cała infrastruktura. Alternatywnie można się przenieść. Kiedyś na tym forum krążył pomysł stworzenia własnego repozytorium dobrego kodu, ale chyba umarł.

Lista komponentów:
phiend.proxy
Pierwotnie nazywało się phiend.handle, ale słowo handler używane jest często i w różnych kontekstach, więc zmieniłem. Rozwinięcie klasy Handle obecnej w WACT, zapewnia lazy loading obiektów. Przekazuje się w kodzie proxy do obiektu, a samo stworzenie obiektu (łącznie z includowaniem pliku z kodem) odbywa się dopiero przy pierwszym użyciu. Kod ukończony, sa nawet unit testy (SimpleTest).

phiend.log
Zestaw klas do obsługi błędów. Inspirowany log4php, ale bez tego strasznego przerostu kodu. Z jednej strony bardzo obiektowy, co zapewnia elastyczne filtrowanie błędów i łatwe dodawanie nowych sposobów obsługi/zapisu błędów. Z drugiej strony najlepsza konsola prezentująca na ekranie informacje o błędzie, jaką do tej pory widziałem. Listing kodu wywalającego błąd i debug_backtrace to standard. Ale podawanie definicji każdej metody z tego backtrace, włącznie z miejscem definicji, nazwami i typem argumentów... mając do dyspozycji Reflection można dużo zrobić. Kod działa, ale na pewno można go dopracować, dopisać nowe handlery, poprawić wygląd konsoli, itd.

phiend.autoload
Prezentowany już tutaj na forum autoloader. Prosty, elastyczny, działający. Bardzo by się do niego przydał (jako osobny projekt) system do mergowania plików z kodem php, ponieważ sam mechanizm autoload w php jest czasochłonny. Ale być może coś takiego da się wykonać przy pomocy Phing...

phiend.auth
Prosty system uwierzytelniania oparty o zagnieżdżone grupy. Na tyle nieskomplikowany, że można go użyć wszędzie, i na tyle rozszerzalny, że można go oprzeć o dowolne źródło (DB, pliki ini, pliki passwd, LDAP, pliki Samby...) tworząc nowy handler. Zainspirowany Solarem i PEAR::Auth, ale znacznie mniejszy i łatwiejszy do dopasowania. Częściowo działa, ale kod jest niedopracowany i niedokończony.

phiend.context
Implementacja request, response i sesji. Temat znany, ale kontrowersyjny, ponieważ trudno ocenić jest obiektywnie, jaki sposób implementacji jest lepszy. Gdyby php miał w tym zakresie jakiś standard... W każdym razie uważam, że jakaś implementacja jest potrzebna, aby można było później rozwijać framework. Kod jest, ale nie jestem do niego przywiązany i z racji skomplikowania tematu nigdy nie byłbym z niego chyba zadowolony.

phiend.registry
Implementacja wzorca Registry. Do rejestru wrzuca się tzw. pluginy, a rejestr zapewnia dostęp do nich, lazy loading oraz prostą implementację Intercepting Filter. Prosty, działający kawałek kodu wydzielony kiedyś z MVC.

phiend.mvc
Framework MVC. Wykorzystuje większość z tego, co opisałem powyżej. Główne cechy:
- cała nie-corowa funkcjonalność wypchnięta do pluginów wrzuconych do rejestru
- przed i po akcjach wykonywane są filtry, implementujące wzorzec Intercepting Filter w postaci dekoratorów
- każda akcja ma konfigurację przekazywaną do filtrów
- akcje można dowolnie dzielić na moduły, a moduły zagnieżdżać w sobie, przy czym konfiguracja jest dziedziczna
- fragmenty corowej funkcjonalnośći również wypchnięte są do pluginów, żeby można było łatwo podmienić (np. router, odczyt konfiguracji dla akcji)
- źródło konfiguracji dla akcji teoretycznie dowolne, chociaż pozostaje implementacja plugina
Całość działała i przechodziła testy, ale potem zacząłem ostro przerabiać/optymalizować kod i skończyłem mniej więcej w połowie.