Witam.

Oto efekt mojej pracy w trakcie ferii:
=> Wersja 1.0
http://vengeance.strefaphp.net/tmp/pinky-framework.tar.gz
=> Wersja 1.1
http://vengeance.strefaphp.net/tmp/pinky-f...work-1.1.tar.gz

W paczce jest dokumentacja wygenerowana przez phpDocumentatora,
pliki frameworku oraz przykładowa strona z niego korzystająca.

Może nie jest to doskonały kod, ale praktyka czyni mistrza
Dlatego prosze o wszelką konstruktywną krytyke.

ps. od razu napomkne, że skrypt hawk-a czyli Phiend był tym, na czym się czasem wzorowałem.

ja bym nie trzymał loginu i hasła mysql w config.xml. Poza tym kontroler nie wie nic o bazie danych (nawet nie wie nic o modelach jeżeli trzymać się MVC) więc też z tego powodu nie powinno być tam tej konfiguracji. U mnie w pliku kernel.xml mam konfigurację bibliotek (router, session, auth itp) oraz definicje akcji, jezeli koder chce, może utworzyć własne pliki xml i odczytywać je przez tę samą klasę.

Ale tez tak mam... procz tego user moze do konfiga dopisywac dowolne rzeczy na swoja potrzebe Zauwaz ze dane odsnosnie loginu i hasla do sql sa w konfigu... ale nie ustawia ich kontroler (klasa Application) tylko plik "startowy". Chcialem tym ograniczyc ilosc miejsc gdzie sa trzymane jakies dane konfiguracyjne ;]

Co do bezpieczenstwa... oczywiscie teraz jest to plik.xml ale potem bedzie do .xml.php

Co teraz o tym sadzisz?

Idąc dalej tym tokiem myślenia, dojdziemy do tego, że hasła do bazy powinny być trzymane w bazie, bo pliki niebezpieczne

@bela_666

[PHP] pobierz, plaintext 
// plik dbconfig.php
<?php
$login
$pass
$host
$db
?>
[PHP] pobierz, plaintext 

udowodnij mi że to nie jest bezpieczne

@Venegance Wolę rozwiązanie, że w pliku kernel.xml jest tylko konfiguracja kernela. Jak koder chce to sobie zrobi własny plik xml

- plik kernel.xml nie rozrasta się niepotrzebnie
- jak chcę doinstalować coś to nie muszę dopisywać linijek do głównego pliku, tylko kopiuję inny plik xml

byc moze. ale zauwaz ze takie rozwiazanie w moim frameworku to takze 5 sekund User po prostu tworzy nową instancję klasy Config I dalej robi co chce. Więc możliwe jest zrobienie i tak, i tak. Jak komu wygodniej

Czemu akcje powiązałeś z wyborem szablonu ? To raczej kontroler powinien dostać dane i wrzucić do widoku

Dziś dorobiłem bajer o którym mowa w tym temacie:
http://forum.php.pl/index.php?showtopic=26107

Uaktualniona wersja do ściągnięcia tu:
http://vengeance.strefaphp.net/tmp/pinky-f...work-1.1.tar.gz

W najbliższym TODO mam do przepisania klase Routera gdyż była robiona troche na "odwal się" i się mi nie podoba

Pozatym, zainteresowanych projektem zapraszam też na
http://devblog.strefaphp.net gdzie co jakiś czas opisuje postępy, testy itd.

Prosze o dalsze oceny i krytyke


--------------edit-----------------
@bela_666: Zamiast rozdzielać na akcje i widoki rozdzielam na coś w tylu akcje logiczne i akcje widoku. Coś ala phiend. Z tymże u mnie wszystkie te akcje wyglądają tak samo ( w phiendzie jedne miały metode display() a inne perform() ) a w konfigu także ich jakoś się nie rozróżnia. Nie robie jakiegoś konkretnego "wrzucania danych do widoku przez kontroler". Dla mnie jest to niepotrzebne komplikowanie kodu.

Pozatym, kontroler wcale nie musi mieć akcji! zauważ, że jest to wzorzec
Model-View-Controller. Akcje są tylko dla naszej wygody i są częścią kontrolera. Czyli jakby nie patrzeć u mnie także kontroler wywołuje ten szablon

Po drugie. U mnie nie szablon jest widokiem a 'showAllNews'. Jest to ta takjaby "akcja widoku". Szablony tylko wspomagają. Wcale ich nie musi być. Akcja równie dobrze może robić zwykłe echo().

Niedługo myśle wprowadzić dwa interfejsy dla akcji logiki i akcji widoku.
Ułatwi to "rozeznanie" się w kodzie jak sądze. Ale to potem dodam.

ps. sorry ze ta wypowiedz jest tragicznie poplątana. Jakoś dziś w ogóle mózg mój nie pracuje

Wiem, że są cześcią kontrolera, no ale jak chcesz pokazać coś jako np. RSS to musisz stworzyć 2 akcje które robię to samo tylko sposób prezentacji jest inny

no to po to masz jeden model, który zwraca Ci dane a Ty w odpowiednim widoku (akcji widoku) formatujesz jak chcesz i volia.