MVC + $_POST, piekło? Opcje

[IMP]

Witam

Temat pewnie nadmiernie eksploatowany jednak nie potrafię znaleźć solucji. Jak jeszcze przykłady obsługi $_GET znalazłem tak nie jestem w stanie ani sobie wyobrazić ani znaleźć takich przykładów dla $_POST. Chciałbym żebyście mnie nakierowali bo zwątpiłem Aby nie odbiec zabardzo od idei MVC action w formularzu powinien wskazywać na index.php. Tylko co dalej? Jak kontroler ma odebrać dane i wybrać odpowiedni widok? Jak to estetycznie połączyć w całość?

Pozdrawiam

[Luneth]

Było: Temat: MVC formularz, filtracja, walidacja, autoryzacja...
Action wskazuje na index.php/nazwamodułu no i w tym module, najczęściej w konstruktorze kontrolera zachodzi sprawdzenie czy otrzymano żądanie POST, jak otrzymano to kontroler zleca wykonanie akcji i na koniec robi przekierowanie, zakładając że np coś dodajesz do bazy

1. Zostaje wysłane żądanie POST.
2. Kontroler bierze sobie widok (tworzy zmienną wskazującą na jego instancję, albo sobie rozszerza klasę widoku, jak kto woli i planuje rozbudowywać cały system, wzorce są wszelakie)
3. Kontroler kojarzy model z widokiem (przekazując mu instancję wybranego modelu)
4. W konstruktorze określono, że user wysłał żądanie POST; zostaje wykonana filtracja/walidacją wysłanych danych, jeśli wszystko poszło ok - kontroler uruchamia daną akcję
5. Zakładając, że akcja została wykonana bez wyrzucenia żadnego wyjątku, kontroler robi przekierowanie.

W modelu zapytania do bazy, zwrócenie gotowych tablic, w widoku kod formularza, cały html no i oczywiście zakładając, że widok jest samoświadomy - pobranie danych z modelu i wsadzenie pól w kod html.

Voila. Jeśli źle to proszę mnie poprawić (jakieś kwiatki, braki składni wybaczcie - późno już... )

Ten post edytował Luneth 15.08.2010, 01:50:03

[Crozin]

Szczerze to nie mam pojęcia w czym może być problem. Czemu formularz miałby wskazywać na index.php? Czym POST różni się od GETa? Jak kontroler ma wybrać odpowiedni widok? Proste: na podstawie sobie tylko znanych kryteriów - dane z POST/GET mogą być częścią ów kryteriów.

[Luneth]

Może autorowi chodziło o samą wzorcową estetykę, bo gdzie metod nie wsadzisz i jakoś im parametrów nie przekażesz - to wszystko będzie działać, autor tez bardzo uogólnił swój problem, nie napisał czy chodzi np o jakiś system komentarzy, autoryzację a może jakiś kalkulator... Czemu formularz wskazuje na index.php? Może chodziło mu o to: index.php/news/ Generalnie wszystkie żądania tam trafiają.

[Crozin]

Na dobrą sprawę dane z POST/GET/COOKIE - to po prostu kolejny model(e).

Czemu formularz wskazuje na index.php? Może chodziło mu o to: index.php/news/ Generalnie wszystkie żądania tam trafiają.

Gwoli ścisłości: to nie ma nic do MVC - kierowanie wszystkiego w jedno miejsce to założenie Front Controllera, nie MVC.

[Luneth]

Masz rację, wszakże front controller często towarzyszy aplikacjom opartym na wzorcu MVC

Ten post edytował Luneth 15.08.2010, 03:54:58

[IMP]

Ciężko mi sprecyzować, ale spróbuje bo widać inaczej się nie da. Chce napisać front kontroler z prawdziwego zdarzenia. Dla przykładu.
Mam wiele formularzy na stronie, głównie znajdujące się w panelu administratora. Nie chce dla każdego takiego Form'a tworzyć nowego pliku .php który będzie go obsługiwał. Co za tym idzie chce wszystkie akcje z Form'ów kierować na index.php. I teraz nie wiem jak podejść do pisania ww kontrolera. W jaki sposób kontroler ma rozpoznać z jakiego formularza pochodzą dane i jaki model do nich dobrać? Proszę jak możecie posiłkujcie się przykładowymi kawałkami kodu. To do mnie przemawia najlepiej.

[Luneth]

[PHP] pobierz, plaintext 
if(isset($_POST['nazwa_formularza_send']){
    // zawartość
}
[PHP] pobierz, plaintext 

Każdy formularz niech ma inną nazwę buttonu wysyłającego/zatwierdzającego i po nim rozpoznawaj. Albo zrób switcha na zmienną $_SERVER['PATH_INFO'] i wysyłaj w action takie żądania: index.php/news/add, index.php/news/edit i zgarniaj to switchem. Model wybieraj w zawartości instrukcji warunkowej.

Ten post edytował Luneth 15.08.2010, 12:33:20

[IMP]

Czyli ogólnie za wiele sobie na wyobrażałem po niektórych lekturach To jest podejście z że tak to ujme przyszłośćia? Nic bardziej Pro nie da się namotać?

Tak czy siak leci "Pomógł"

[Luneth]

Zawsze można bardziej namotać niż jest potrzebne Ja bym w Twoim przypadku zrobił tak jak napisałem, a jeśli ktoś inny ma tutaj bardziej "Pro" pomysł, to pewnie się tu wypowie
Czy z przyszłością? Myślę, że tak, jak będziesz chciał sobie inaczej wszystko rozłożyć na poszczególne kontrolery dla każdego formularza to uprościsz front controller a resztę przełożysz do tych 'mini' kontrolerów, nie będzie trzeba wszystkiego przepisywać od nowa

Ten post edytował Luneth 15.08.2010, 13:07:28

[skrypta]

zerknij na przyklad uproszczonego front controllera
http://skrypta.pl/skrypty-php/budujemy-wla...esc-1-podstawy/

nie sadze abys musial wprowadzac inna obsluge dla POST i GET, wystarczy to zrobic na REQUEST chyba ze masz na tyle szczegolny przypadek ze musisz wiedziec jaka metoda do ciebie trafily dane, ja osobiscie nie lubie jak moj front controller decyduje o podjeciu wszystkich akcji, raczej kieruje sterowanie z front controllera do kontrolera w ktorym w konstruktorze moge nadpisac funkcjonalnosc i stamtad pokierowac do odpowiedniej akcji, oczywiscie wszystko zalezy od specyfiki twojego systemu - jak napiszsz uniwersalny front controller to szybko zauwazysz ze kilka rzeczy ci w nim przeszkadza i cie ogranicza ) ale pisanie to jedyna droga do nauki

pozdr