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

[squid]

wg mnie nie jest tak zle (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Oczywiscie ze nie wszystko jest pieknie i rozowo ale tak jest zawsze, zeby framework byl czms wiecej niz przelotnym pomyslem jednej osoby trzeba pracujacej grupy a nie jednej osoby bo ona (ta osoba) narzuca swoje rozwiazania nie widza problemu z innych perspektyw, to jest ANTI-REUSEABLE. Moze i nie monza zbudowac takiego kodu w php ale moze warto by sie skupic nad samamym szkieletem frameworka (wiem ze to gluio brzmi). Chyba kazy kto przegladal zrodelka chcialby dodac cos od siebi, uzyc czegos innego itd. Moze wiec wypracowac jakies wspolne API i jak ma to wszystko dzialac aby bylo maksymalnie elastycznie. Idea budowania aplikacji z klockow bardzo mi sie podoba ale bez szkieletu klocki sie posklejaja. Interfejsy mysle ze tu duzo daja ale to za malo. Mysle ze dobrze byloby zrobic taka wyliczanke, podzielic wszystkie zadania na fragmenty i napisac taka klasa ma takie wlasciwosci i metody, takie argumenty (zgodnie z idea programowania defensywnego sprawdzac czy all jest ok) i na tej podstawie zaczac pisac bo bedzie to o wiele leastyczniejsze kiedy bedziemy wiedziec czym ma sie dany kawalek kodu zajac a to jak to sie zaimplementuje to rzecz gustu.