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]

Mam wrażenie , że reaktywacja zakończyła się totalną klapą, i coraz bardziej mnie to wkurza. Czemu?

Teraz każdy pisze swój framework. Nieważne po co, nieważne w czym ma być lepszy niż inne - ma być i koniec. Z tego powodu przestałem lubić słowo "framework". I phiend2 nie jest frameworkiem. Jest czymś w rodzaju WACT, przynajmniej w teorii. W praktyce WACT jest właśnie frameworkiem. Bardzo dobrym, ale nie rozumiem, dlaczego dlaczego muszę używać ich error handlera razem z ich szablonami. Framework == wszystko w jednym, bierzesz całość albo nic. A nazwa WACT sugeruje coś innego - Component Toolkit, czyli zbiór komponentów do wykorzystania w swoich projektach. W tym i w swoich frameworkach, jeżeli ktoś musi mieć własny.

Ale miało być o phiend2, nie o WACT. To, co na początku było frameworkiem o nazwie phiend2, zostało podzielone na szereg pakietów o nazwach phiend.cośtam. Nie dlatego, żeby więcej razy występowało słowo "phiend", tylko dlatego, żeby nie robić z tego wielkiego frameworka, tylko zbiór praktycznych komponentów. Które pasują do siebie i wykorzystują się nawzajem, ale mogą być stosunkowo łatwo używane w innych projektach.

I co z tego wyszło? Po pierwsze, ludzie, którzy deklarują chęć pomocy, ale nie potrafią zrobić coś konkretnego. OK, zdaję sobie sprawę, że tworzenie takich komponentów to trudna sprawa. Kod własnego frameworka można sobie pisać, jak się komu podoba. Kod wielokrotnie używanej (w zamierzeniu) biblioteki musi być dopracowany i optymalny. Ale jeżeli miałbym najpierw tłumaczyć szczegółówo, o co chodzi, pokazywać jakąś dokumentację, diagramy, itd., to mi się to nie opłaca, bo szybciej sam bym zrobił co trzeba. Tak naprawdę potrzeba mi nowych pomysłów i krytycznego spojrzenia, a nie przypominam sobie, żeby ktokolwiek wskazał jakieś ulepszenie albo wskazał konkretny fragment, który mu się nie podoba.

Po drugie, najważniejsze, mam wrażenie że nikt nie chce brać w tym udziału. Dostałem już sporo PW w stylu "podoba mi się pakiet phiend.cośtam, czy mogę wykorzystać twój kod w swoim frameworku?". Przecież to jest bez sensu! Gdyby ktoś mi napisał, że podoba mu się pewne rozwiązanie, ale nie może zastosować całości, ponieważ ma inne (jakie?) wymagania, to rozumiem. Ale jak komuś się podoba jakiś komponent, to należy go wykorzystać, a nie przepisywać od nowa. Na tym polega istota komponentu. Reużywalność, a nie copy-paste.

W php najbardziej zniechęca mnie to, że bardzo mało jest reużywalności. Każdy framework jest niezależny. Każda biblioteka niekompatybilna z innymi. No prawie. Ręce mi opadają, jak widzę, że np. Mojavi zawiera własny driver do bazy danych, WACT też, itd, itd. Ja mogę o swoim kodzie powiedzieć, że albo jest wymyślony od początku przeze mnie, albo zaczerpnąłem pomysł od kogoś innego, ale przynajmniej mogę uzasadnić, dlaczego musiałem napisać go od nowa. Np. phiend.handle inspirowany jest klasą Handle z WACT, ale po pierwsze implementacja jest inna, a po drugie autorzy uparli się, że nie można używać klasy Handle bez ich szablonów. A cała ta reaktywacja phiend2 skończy się pewnie tym, że phienda2 jak nie było, tak nie będzie, ale za to będziemy mieli kilkanaście frameworków zawierających przypadkowo wyrwane fragmenty kodu, nijak nie pasujące do siebie nawzajem.