Piszę (w celach ćwiczenia) klasę uwierzytelniania. W klasie mam metody takie jak, check_if_logged, connect_to_databese itd... są to metody które są zdecydowanie w backendzie. A co z frontend'em? Powiedzmy przydałaby się metoda wyswietlajaca formularz logowania. I teraz jeśli dam po prostu: 

[PHP] pobierz, plaintext 
public function display_login_form(){
 
echo " // tutaj cały formularz
 
";
 
}
[PHP] pobierz, plaintext 

To będzie to wystarczająco oddzielone? 

Czy może, nie wiem, mieć zapisany formularz w oddzielnym pliku tekstowym i includować go w metodzie?

witaj,
moim zdaniem lepszym rozwiązaniem będzie właśnie includowanie owego formularza.



oczywiście w f_login.php umieść ten formularz ;]

pozdrawiam!

A moim skromnym zdaniem odpowiednim wyjściem będzie zastosowanie systemu szablonów i po prostu użyć go w tej metodzie...

Tzn, użyc np. smarty? Czy samemu napisać?

Z tego, co napisałeś, to strasznie pomieszałeś wszystko. Po co klasa uwierzytelniania ma się zajmować połączeniem z bazą danych? Ono powinno już gotowe istnieć i czekać na nią. Podobnie jest z logowaniem - klasa uwierzytelniania na pewno nie powinna się tym zajmować od A do Z. Zamiast tego raczej udostępnij metody pozwalające taki formularz logowania programiście odpowiednio oprogramować. Niech sprawdzają one, czy użytkownik istnieje, czy zostało podane dobre hasło i zwracają jakiś wynik. W zupełnie innym miejscu piszesz formularz logowania, który może być zrobiony jako jedna z akcji. Akcja wykorzysta wtedy interfejs klasy uwierzytelniania do sprawdzenia, czy dane są poprawne i wyświetli rezultat.

Natomiast to, jak wyświetlisz w formularzu kod HTML, to jest sprawa drugorzędna z punktu widzenia uwierzytelniania. Jeśli jednak już decydujesz się na system szablonów, to nie pisz własnego, chyba że Ci się bardzo nudzi i chcesz się nauczyć, jak to działa.

Czyli czym dokładnie powinna się zajmować klasa uwierzytelniania? Sprawdzeniem czy użytkownik istnieje, czy podaje dobre hasło, utworzeniem dla niego sesji, zapisaniem ciasteczek, wylogowaniem usera. Czy jednak całkiem w złym kierunku myślę?

Mniej więcej tym, co podałeś. Sporo zależy od Twoich potrzeb. Przykładowo, w jakimś prostym systemie oczywiste jest, że autoryzuje się po to, by kogoś zalogować, ale w dużych aplikacjach wcale nie musi to być prawda: autoryzacji możesz potrzebować też do innych celów lub też może istnieć kilka różnych mechanizmów logowania (zwykłe logowanie, odciski palców, itd. ). Wtedy tworzy się kilka różnych klas uwierzytelniania, które mają jednakowy interfejs, a następnie wykorzystuje je w jakimś miejscu, które coś z wynikiem dalej robi (np. tworzy sesję). Dzięki temu kod odpowiedzialny za tworzenie sesji zadziała bez względu na to, czy będzie dokonywać autoryzacji przy pomocy klasy uwierzytelniania "login i hasło" czy też "odciski palców".

Podam Ci przykład z systemu, nad którym właśnie siedzę. Mam tam dwie klasy uwierzytelniania:
- Logowanie z formularza - podajesz login i hasło. W odpowiedzi dostajesz profil użytkownika lub komunikat błędu.
- Uwierzytelnianie sesji - sprawdza, czy już istniejąca sesja wskazuje na właściwego użytkownika. W odpowiedzi dostajesz profil użytkownika lub komunikat błędu.

Korzystam z nich w dwóch miejscach:

1. Formularz logowania - związany jest z pierwszą klasą. Po przyjściu danych odpytuje on jej obiekt i dzięki temu określa, czy użytkownik wpisał poprawne dane czy nie.
2. Inicjowanie sesji - po załadowaniu sesji korzysta z drugiej klasy do sprawdzenia, czy i kto jest zalogowany. Jeśli ktoś jest, uzyskujemy jego profil, który zapamiętujemy, by cała strona mogła z tego korzystać.

Nic ciekawego tu na razie specjalnie nie ma, gdyż poza tym, że obie klasy mają wspólny interfejs, są generalnie niezależne. Ale zauważ, że niebawem będę chciał napisać np. moduł pamiętania sesji. Wtedy wystarczy, że napiszę sobie trzecią klasę uwierzytelniania i podłączę ją do drugiego przypadku, równolegle z już istniejącą klasą. Można sobie też wyobrazić, że będą jakieś miejsca wymagające dodatkowego logowania, aby zyskać jeszcze wyższe uprawnienia. Ponownie, mogę stworzyć następną klasę logowania i tym razem podłączyć ją pod formularz logowania, w którym nie będę musiał zmieniać ani jednej linijki kodu, by zaczął współpracować z nowym systemem uwierzytelniającym.

A teraz wyobraźmy sobie panel do konfigurowania zabezpieczeń, w którym mamy interfejs do składania takiej autoryzacji wizualnie. Jak chcemy w którymś miejscu utworzyć logowanie, to klikamy "Wstaw tu formularz logowania" i wybieramy klasę uwierzytelniającą, która z nim będzie współpracować, a system już sobie z tego poskłada resztę.

Tak więc w moim przypadku klas uwierzytelniania jest więcej, i w dodatku nawet nie zajmują się one specjalnie sesjami .

A czy coś takiego będzie poprawną metodą?
log_in
W argumentach przyjmuj nazwę usera i hasło.
Sprawdza czy hasz hasła pasuje do zapisanego w bazie hasza hasła dla danego usera.
Jeśli nie to wywala error
Jeśli pasuje to: dopisuje w tabeli z userami w polu "logged_in" yes (dla danego usera), tworzy $_SESSION['logged] = 'yes', wywoluje metode sprawdzajaca czy user wybral "zaloguj automatycznie) i jeśli zwraca TRUE to jeszcze setcookie('logged', sha1(haslo));

Szczególnie chodzi mi o części z bazą danych

A nie możesz po prostu zerknąć jak to jest zrobione we frameworkach jak Zend_Auth? Masz klasę adaptera np bazę danych którą możesz odpytać również niezależnie (getDbSelect()) oraz storage w tym wypadku sesję która tworzy nową "przestrzeń nazw". Do logowania tworzysz zwykły formularz w kontrolerze np. user/loguj i sprawdzasz poprawność wprowadzonych danych przez Zend_Auth->setCredential itd. Żadnego wciskania funkcjonalności do klas które za to nie odpowiadają.

Nigdy nie spotkałem się z Zend'em. Jestem początkującym, dzięki za radę. Tylko tam jest chyba model - kontroler - widok przestrzegany. Razem z oddzielnymi katalogami na to itd... U siebie tego nie wprowadziłem. 

Ty masz patrzeć na komponent Zend_Auth, a nie na MVC tam . Nawiasem mówiąc przykład, który podawałem, jest właśnie na Zend Frameworku zrobiony.