[skrypt] - Szkielet dla aplikacji Opcje

[adbacz]

Witam, od jakiegoś czasu piszę szkielet dla aplikacji. Wiem, że to wynajdywanie koła na nowo, ale uznaje to za naukę. Cała aplikacja znajduje sie pod linkiem na dole. Proszę o ocenę kodu, na co mam zwrócić uwagę, co robię źle a co jest ok. Tylko proszę bez zbędnych stwierdzeń "po co Ci to, lepiej zajmij się czymś pożytecznym" - a nauka to nie pożytek?

Próbowałem pisać wszystko należycie dla PHP 5.3 wzwyż. Zastosowałem minimalnie dostosowany wzorzec MVC, DependencyInjection
(wiem, że to może być katastrofa więc prosze o opinie), podział na komponenty oraz monstrualnę konfigurację. Nie przestraszcie się wglądając do pliku config.php, wszystko jest po mojej myśli.

Zdaję sobie sprawę, że to nie jest ukończone nawet w 50%. Muszę jeszcze poprawić zarządzanie bazą danych oraz użytkownikami, tak samo musze pomyśleć nad usunięciem zbędnego kodu z klasy Kernel, ale na tą chwilę wszystko działa.

W razie jakich kolwiek pytań chętnie na nie odpowiem.

Link do pliku *.zip: LINK

[!*!]

- jak coś pakujesz, to spakuj cały katalog a nie jego zawartość
- co to jest?

//==============================================================================
//==============================================================================

To chyba powinna zastąpić dobra dokumentacja kodu
Nie bardzo rozumiem podział...
- Dlaczego w katalogu /web jest index.php?
- w katalogu Application jest View, ale nie ma models, controlers? Czy to działa z podziałem na katalogi, jeśli tak, to "Components" niewiele mówi.
- jak wczytujesz klasy? Widzę że masz coś takiego jak Kernel, ale nie bardzo wiem, czy te spl można rozbudować.

[adbacz]

1. Będę pamiętał
2. Z przyzwyczajenia wstawiam żeby oddzielić metody. Ich opis przeważnie jest tam gdzie powinien. Wiem, że nie umiem dokumentować...
3. To miał być podział. Planowałem w katalogu web jeszcze trzymać cache ale wątpię, żeby to był dobry pomysł. Jakieś wskazówki?
4. W katalogu Application/View są główne widoki, które są sklejane z innymi. Te inne znajdują się np. Application/Components/Publications/View
5. Na razie używam czystej funkcji ale mam zamiar napisać klasę do ich ładowania.

"...ale nie bardzo wiem, czy te spl można rozbudować." - Tzn?

[!*!]

SPL głównie powstało po to aby się nie ograniczać. Dajesz możliwość utworzenia własnych namespace/śceiżek do klas? Jak ktoś będzie chciał dodać np. smarty, to jak to będzie u Ciebie?

2. Z przyzwyczajenia wstawiam żeby oddzielić metody.

ale po co? Żeby lepiej były widoczne? w ostatniej klamrze metody daj } // end function blebleble() nie potrzebne są takie znaczki.

4. W katalogu Application/View są główne widoki, które są sklejane z innymi. Te inne znajdują się np. Application/Components/Publications/View

Tylko po co wtedy jest ten katalog tam? Skoro i tak wczytujesz z Application/Components/Publications/View

[adbacz]

Smarty to system zarządzania Widokami czy tez templatkami, więc wystarczy, że doda główna klasę Smarty jako serwis, zaimplementuje odpowiedni interfejs i ustawi nazwę serwisu w pliku konfiguracyjnym. Można też zamiast implementacji interfejsu przez klasy Smarty napisać pośredniczącą klasę i ją ustawić jako serwis itd. Każdy system tempatingu musi implementować interfejs, aby mógł współdziałać.

Ogólnie rzecz biorąc, to gdy mamy kontroler, i ten zwraca definicję widoku, składa się ona z widoku należącego do danego komponentu, w tym przypadku będzie to jakiś widok z Application/Components/Publications/View, a opcjonalnym parametrem jest nazwa głównego widoku, do którego wklejana jest treść tego mniejszego widoku z naszego komponentu.

EDIT
Mój błąd polega na tym, że zapomniałem o używaniu zewnętrznych bibliotek, które przecież mają własne namespaces. Musze napisać "ładowarkę".

Ten post edytował adbacz 8.07.2012, 15:43:40

[Spawnm]

[PHP] pobierz, plaintext 
$link = @mysql_connect
[PHP] pobierz, plaintext 

Czemu nie PDO?! D:

[adbacz]

Bo kiedyś napisałem klasę i uzyłem ją tutaj. Z resztą w pierwszym poście: "Muszę jeszcze poprawić zarządzanie bazą danych"...