Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [skrypt] - Szkielet dla aplikacji
Forum PHP.pl > Inne > Oceny
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?
Cytat
//==============================================================================
//==============================================================================

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?

Cytat
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.

Cytat
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ę".
Spawnm
  1. $link = @mysql_connect

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"... wink.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.