Witam,

Od jakiegoś czasu pracuję na własnym nieskomplikowanym frameworku. Lata doświadczenia przyniosły wiele ciekawych pomysłów, nie zawsze spotykanych w innych frameworkach, które usprawniają pracę czy czynią wykonanie porządniejszym. Chciałbym abyśmy powymieniali się własnymi praktykami, tworząc zbiór propozycji, który jednocześnie będzie stanowił listę rzeczy, nad którymi powinni zastanowić się początkujący zaczynając nowy serwis/skrypt.

Zacznę od swoich pomysłów, zachęcam do dzielenia się.

- katalog z frameworkiem może leżeć oddzielnie i być wykorzystywany przez kilka aplikacji, dzięki czemu poprawek błędów czy nowych funkcji nie trzeba nanosić/kopiować na wiele plików.
- cały frontend (szablony, js, grafika itd.) w jednym podkatalogu, co pozwala stworzyć osobne konto ssh/ftp dla front end designera, bez dawania mu dostępu do kodu aplikacji
- autoselector konfiguracji w zależności od aktualnego hosta (localhost, domena itd.) pozwalający dokonać deploymentu kopiując cały katalog na serwer razem z configami
- wykrywa dostęp zdalny po zewnętrznym IP do lokalnego hosta i ładuje poprawnie konfigurację lokalną co pozwala np. zgłaszanie statusu płatności na nasz localhost podczas tworzenia
- przechwytywanie i logowanie wszystkich błędów ze stack tracem itp (error handler, exception handler, shutdown handler)
- tłumienie błędów innych używanych bibliotek np. FPDF (funkcje do chwilowego wyłączania raportowania błędów)
- "dwukierunkowy" router, tzn linki w szablonach wstawiamy funkcją np link('user/register'); i jeżeli w routerze dodamy "podmianę" tego linku na "rejestracja/" to link zmiania się zarówno w HTML strony jak i działa po kliknięciu odpowiednio
- wielojęzykowość przez własny plugin w szablonach (np outputfilter w SMARTY pozwalający zapisywać wielojęzykowe teksty np. tak: @Witaj użytkowniku@ (w jakimś pliku zawieramy odpowiedniki do podmiany, dla wydajności można zrobić kilka katalogów kompilacji smarty i zamiast outputfilter zastosować filtr już przy kompilacji szablonu)
- komunikaty dla użytkownika o wykonanej akcji - praktycznie w każdym serwisie mamy powiadomienia, że jakaś akcja została wywołana. Warto sobie to uprościć funkcjami typu actionMessage('Plik dodano'), errorMessage('Nie udało się') - framework zbiera wywołania do tablicy i przekazuje do szablonów liste komunikatów do wyświetlenia
- bogaty system redirectowania, z możliwością pokazania komunikatu po redirecie jak wyżej (redirecty typu zwykły i skrócone formy - "przekieruj na główną z komunikatem, że musi być zalogowany jeżeli nie jest" "przekieruj na główną z komunikatem brak uprawnień jeżeli nie ma danego uprawnienia" w formie pojedynczych wywołań funkcji itp.)
- htacces przekierowujący wywołania do index.php, wyłączający listowanie katalogów itp.
- zabezpieczenie CSRF
- modele z abstrakcją do bazy danych np. PDO i uniwersalnymi funkcjami jeżeli nie stosujemy ORM (np. getId, getWhere, updateWhere. Pamiętajmy o możliwości pobrania tylko niektórych pól, o przekazywaniu insertów i updatów jako zestaw danych do zbindowania np. ciąg znaków jak i dodatkowo nie bindowanych np. pkt=pkt+1 albo NOW() )
- stałe notyfikacje wyświetlane użytkownikowi aż do ich zamknięcia przez kliknięcie w X (trzymane w sesji)
- proste wywołanie zliczające ile razy akcja o pewnej nazwie np. "register" jest wywołana, jeżeli wywołanie zliczy nadmierną ilość akcji w czasie to nie pozwala na wykonanie akcji np. doLimitPerHour( 'register' , 5 ), może działać po IP itp.
- rozbudowany system formularzy z walidatorami, i powiązaniem z bazą, tak by dodawanie nowego pola z kilkoma warunkami walidacji i "spięcie" tego CRUDEM z bazą danych to było kilka linijek (formularze to temat na osobny taki thread, więc nie będę się tu rozpisywał, wiadomo, że warto mieć zestaw swoich "pól" typu input, select na podstawie podanego arraya z validacją, wiele chceckboxów/radio z arraya, daty złożone z 3 selectów lub inputa z jQuery datepickerem itp.)
- system skalowania obrazów do kilku lokalzacji i w róznych formach (po dłuższym boku, w kwadrat itd.)
- system kategorii (drzewo)
- obsługa uprawnień
- Utilsy do przekształcania dat SQL na lepiej wyglądającem, z nazwanymi miesiącami itp.
- składania głównych modułów z pomniejszych "modulików" uniwersalnych typu upload pliku, upload zdjęcia, upload kilku zdjęć, wpis wielokrotny przez dodawanie kolejnych inputów (lub zestawów inputów) z poziomu JS
- system kolejkowania e-maili i wysyłania ich z crona
- panel dla administratora pozwalający jednym klikiem np. przelogować się na innego użytkownika (fajna sprawa przy testowaniu)

a rozwiń to: zabezpieczenie CSRF ? (tzn nie definicję, tylko co stosujesz jako zapezpieczenie)

od siebie dorzucę: parametryzowane położenie statycznego contentu: grafiki, js, css. przydatne jak chcemy wrzucić cały ten syf na osobny serwer (fast static, np nginx)

Jest to powiązane ściśle z całym systemem formularzy jaki mamy. Jeżeli mamy system formularzy i ich walidacji to warto sobie dodać do nich metodę/funkcję csrf, która będzie walidować czy hash przesłany przez formularz (lub nawet link i GET) jest zgodny w przygotowanym w poprzednim wygenerowaniu strony. Czyli po krótce jakieś wywołanie w PHP które wygeneruje i zapamięta hash, oraz np. wywołanie funkcji/metody obiektu w szablonach który wstawi ostatnio generowany hash do input hidden)

Czyli po krótce chodzi o to, żeby możliwie jedną-dwoma linijkami kodu zapewnić sobie sprawdzenie, czy formularz został odczytany a następnie zapostowany, czy POST przyleciał sztucznie z jakiejś podejżanej strony, która podłożyła userowi wypełniony formularz i JSem za submitowała go w nasz serwis.

W linkach może to być przydatne np. jeżeli stosujemy linki do usuwania kontentu. Można wygenerować i zapamiętać hash do sprawdzenia, a następnie przekazać go w linku (np. usun/id/4/js7fn3k28dfna8).

Dodam jeszcze

- pamiętajmy o POST-REDIRECT-GET (redrectujmy po wykonaniu akcji z formularzy)
- wsparcie dla AJAX (żeby outputem z controllera mógł być czysto-tekstowy szablon bez layoutu lub po prostu JSON)
- mechanizmy filtracji contentu użytkownika (czasami potrzebujemy plaintext, ale czasami przyda się dozwolić kilka tagów HTML np. dla WYSIWYG)
- CRUD z rozbudowanym R, czyli nie tylko oglądanie wpisu, ale także listowanie ze stronicowaniem + kryteriami + sortowaniem w różnych kierunkach + możliwość łączenia kilku kryteriów (np. cena większa niż coś + w nazwie zawiera coś)

- pamiętajmy o POST-REDIRECT-GET (redrectujmy po wykonaniu akcji z formularzy) - a to do czego?

a z dobrych praktyk, może nie programowania, ale organizacji infrastruktury - to trzymanie kodu w svn/git i automatyzacja publikacji kodu na serwerach dev/produkcyjnych.
(przy czym git ma nad svn'em miażdżącą przewagę i w tym aspekcie)

Może nie dotyczy ściśle frameworka ale ogólnie PHP, dzięki redirecie po akcji pozbywamy się metody POST i danych formularza, dzięki temu odświerzenie nie wysyła ponownie formularza, nie pyta użytkownika o ponowne wysłanie. Możemy też przemycić jakąś akcję w linku a następnie z redirectować na ładny link.

Dorzucam:

- Oznaczanie elementów formularzy i linków przez id/rel, aby łatwo było się do nich odnieść w testach selenium
- Testy selenium, które przy okazji generują nam testowy losowy content w serwisie, dzięki czemu mamy pogląd na całość, ze stronicowaniem itd. bez ręcznej roboty
- Trzymać się "globalnego adresu" np. założyć na localu hosta http://serwis.local/ dzięki czemu możemy wszędzie posługiwać się globalnym odwołaniem (szczególnie ważne przy wywołaniach AJAX w plikach .JS, nie musimy przy wrzucaniu na produkcję podmieniać adresów do serwisu tylko wszędzie zaczynamy do /)
- Jakiś przycisk, który nam uzupełnia poprzez JS pola formularzy losowymi ciągami/lorem ipsum - ułatwia testownie

A wyjątki pozwalające na wygodne wyplucie statusu http?