[fw] Spawn 2.4 Opcje

[Spawnm]

Witam,

prosił bym o opinie na temat najnowszej wersji mojego FW.
Konkretnie interesuje mnie wasze zdanie co byście w nim chcieli jeszcze zobaczyć lub zmienić aby jeszcze przyjemniej się w nim pisało.
Jako że zabieram się za pisanie polskiej dokumentacji, interesuje mnie co wydaje wam się niejasne, trudne do zrozumienia w tutorialu na stronie.
Wiem że obecnie to bardziej zbiór przykładowych kodów, ale i tak jestem ciekaw czy coś pominąłem co dla osoby która nigdy nie pisała w fw może być niezrozumiałe.

http://spawnframework.com/



Tak, wiem, nie ma testów jednostkowych.

[Crozin]

Odnośnie tych podkreśleń: zdecydowana większość właściwości obiektów jest niepubliczna, stąd wrzucanie tych durnych znaków podkreślenia nie stanowi żadnej wskazówki dla programisty - od tego ma IDE.

Sam projekt, raczej słaby:
1. Brak wsparcia dla Composera; w głównym repozytorium jakieś przykładowe aplikacje - brak możliwości wygodnej aktualizacji FW.
2. Brak jakiejkolwiek współpracy z innymi bibliotekami, poza wspomnianym Bootstrapem Twittera, który nigdy nie powinien się tu znaleźć. Po co wszystko wymyślać koło od nowa, szczególnie gdy jest to kanciaste koło?
3. Kulejący angielski, słabo/nieudokumentowane API.
4. Na pierwszy rzut oka bardzo restrykcyjne wymuszenie szkieletu aplikacji.
5. Kompletnie nieodpowiednie nazewnictwo. Dlaczego w katalogu Bin są zwykłe pliki konfiguracyjne? Klasa Spawn\Math przecież też zbyt wiele wspólnego z biblioteką matematyczną nie ma. Albo klasa Spawn\DI (chyba chodziło o Dependency Injection Container, tak?), która z DICem wiele wspólnego nie ma, a jest zwykłym kontenerem na dane.
6. Nadużywane metod magicznych.
7. Źle używane przestrzenie nazw. Dlaczego klasa Spawn\Acl nie znajduje się w przestrzeni nazw Spawn\Acl? (przy okazji tutaj dobrze widać, dlaczego deweloperzy PHP dali ciała forsując użycie wielkich liter w fragmentach nazw przestrzeni nazw); Zaś sama przestrzeń Spawn to już misz-masz wszystkiego. Dodatkowo mimo wszystko korzystasz z globalnej przestrzeni nazw.
8. Większość "elementów" FW to w zasadzie zwykłe klasy pomocnicze (patrz: Mail, Math, Log, Url, Download itp.) W dodatku większość z nich przez fakt użycia metod statycznych jest mało przydatna.
9. Nie trzymasz się podstawowych reguł tworzenia dobrego kodu, tj. nie korzystasz z interfejsów (interface-based/interface-driven design), nie korzystasz z wstrzykiwania zależności. Przez to praktycznie nie da się ingerować bezkonfliktowo w elementy FW.
10. Nie widzę niczego czym projekt ten miałby wybijać się ponad istniejące rozwiązania (i mówię tutaj raczej o tych z "niższej półki" typu Kohana, CI).

Podsumowując: jednak nie "raczej słaby", a po prostu słaby.