Witam.
Zazdroszczę takiej pracy.
Osobiście sprawy validatorów kodu xhtml czy css zostawiłbym na koniec, bo wg mnie (oczywiście zaraz będzie krytyka
)
bawić się w validację to tak jak zamiatać chodnik po jego zbudowaniu.
Strona się dobrze wyświetla w FF Ie7, IE8, Operze i kilku innych - jest ok.
Jeśli nie współpracujesz z fanatycznym kolesiem tworzącym szablony, który po prostu musi mieć wszystko jak należy, to kilka errorów w walidatorze
nie jest problemem.
No chyba, że chcesz stronę wyświetlac na czymś więcej niż monitor komputera.
Piszę tak, bo na pewno nie jesteś osobą, co zapomni sobie zamknąć tag <h1> i dziwi się co jest grane na ekranie.
Wspomagacze jak szablony Smarty nie są potrzebne do szczęścia.
W samym PHP można tworzyć szablony.
Przykład:
ftp://ftp.helion.pl/przyklady/php5tp.ziprozdział 11.
Ale lepiej nie rezygnować z jakichkolwiek szablonów, bo późniejsza zmiana wyglądu strony bedzie bardzo kłopotliwa.
DOM - to API dla obiektów tworzących dany dokument.
Służy do zarządzania obiektami tworzącymi stronę www.
Osobiście nigdy nie myślę nawet o tym, gdy aplikacja ma być skuteczna, a nie super ładna.
Ogólnoświatowe konwencje pisania kodu, to chyba dzisiaj wzorzec MVC.
Osobno masz dostęb do danych (model - M), osobno logikę (kontroler - C) i osobno wyświetlanie wszystkiego (widok V).
Zmiana w jednej częsci nie powoduje konieczności ingerencji w drugą.
Zamiana zapisanych informacji w plikach na zapis ich w bazie danych nie powoduje strat moralnych oprócz tego, że trzeba
przerobić Model.
Są do tego frameworki (np. Symfony) ale bez frameworka też można samemu sensownie wszystko poukładać.
Pisanie strukturalne - jedna dziedzina problemu - jedno rozwiązanie (np. Turbo Pascal) - dzieś się tego nie stosuje, bynajmniej nie przy www,
Pisanie proceduralne - to tzw. styl wolnych funkcji. Funkcje rozwiązują konkretny problem i zwracają jedną informację (np. sinus kąta) lub procedury rozwiązuja problem
i zwracają zero lub więcej niż jedeną informację (np. włączenie muzyczki - nie zwraca żadnej informacji).
Każdy ma dostęp do takiej funkcji.
Możesz do takowej wrzucić stringa, choć wymaga boolean'a i bez ciągłego debugowania namnożą się ciekawe błędy.
Nie masz też dziedziczenia, a więc tzw. polimorfizm odpada (który np. pozwala ograniczyć ogromne ilości instrukcji warunkowych do jednej).
Porównaj wizytówkę na 3 przykładach - to wyjaśnia ewolucję porcji informacji od zmiennej w kierunku obiektu.
1. zmienne - każda informacja (imię, nazwisko, telefon) to osobna zmienna,
2. tablice - wszystkie informacje z wizytówki znajdują się w jednej tablicy,
3. obiekty - wszystkie informacje w jednym obiekcie + funkcje do operowania na tych informacjach + ograniczony dostęp (obiekt od
wygrywania muzyki nie uruchomi przez pomyłkę funkcji dla obiektów od wyświetlania wizytówek i nie spowoduje błędu).
Od Ciebie zależy wybór. Obiekty są "lepsze" ale trzeba się ich poprostu nauczyć.
U mnie w firmie wolą przyjąć osobę (bez doświadczenia, zaraz po studiach) do programowania obiektowego w C++, która
co kolwiek robiła obiektowo i nie zna składni języka C (podobna do C++), niż taką co zna składnię C, ale nie kojarzy obiektów.
Ciekawy jestem jednej rzeczy - DLACZEGO PHP I SQLITE
?
Pozdrawiam
