MVC - wcale nie takie cudne? Opcje

[cicik]

Człowiek uczy się całe życie.
Od kilku lat wszystkie prace, które wykonuję bazują na szkielecie, który rozbudowuję przez cały ten czas.
Szkielet ten polega na tym, że mam moduły (jeden moduł - jedna klasa), w których zdefiniowane są poszczególne zadania wykonywane przez moduł (jedno zadanie - jedna metoda). Na przykład za dodanie artykułu do bazy odpowiedzialna jest jedna z metod odpowiedniej klasy.

Jedna z zasad OOP mówi, że jeżeli moduł A chce żeby było zrobione coś co dotyczy modułu B to najlepiej niech moduł B zrobi to sam bo on wie najlepiej jak to zrobić. Przykład ilustrjący tę zasade w moim przypadku:

Jest moduł do zarządzania grupami użytkowników. Jednym z jego zadań jest definiowanie praw dostępu.
Prawa są wyswietlane dla każdego zainstalowanego modułu w formie rozwijanego drzewka, w którym użytkownik zaznacza odpowiednie checkboxy. Aby skonstruować to drzewko moduł zarządzajacy grupami includuje każdy moduł. Każdy z includowanych modułów zawiera metodę, która otzrymuje referencę do obiektu symblizującego generowane drzewko. Zadaniem tej metody jest dodanie do drzewka checkboxów konkretnego modułu.

Wszystko działa pięknie, chuczy, buczy, lata i gada.

Tylko jest jeden problem. Każdy z modułów zawiera 500 - 1000 linijek kodu. jeżeli modułów jest powiedzmy 20 to aby wygenerować to drzewko potrzeba przeparsować całą masękodu po to aby w ażdym dołączonym module skorzystać z jednej metody zawierającej pięć linijek.

Masakra!

I oto myślę sobie: "Kurcze MVC pomoże. Każdy moduł rozbiję na szereg akcji, widoków i elementów modułu i będzie fajnie. Przy każdym żądaniu będę includował tylko to co trzeba."
No i faktycznie rozbiłem kilka przykładowych modułów zgodnie z paradygmatem MVC i jest super.
Tylko natrafiłem na problem, z którym nie bardzo umiem dać sobie radę.

Chodzi o formularze w panelu administracyjnym np. do dodawania użytkowników, artykułów etc.)
Generalnie zasada jest taka:

1. Trzeba dodać użytkownika - ładuje się widok z formularzem.
2. User wypełnia formularz, klika guzik
3. uruchamiana jest akcja dodajaca usera. Jęzli formularz był wypełniony dobrze to dane są zapisywane i ładowany jest widok z listą użytkowników. Jeśli zaś dane zostały wpisane źle to ładowany jest ponownie widok z formularzem.

Teoria piękna (jak to zwykle z teoriami bywa), natomiast z praktyką trohe gorzej.
Przy okazji budowania dotychczasowych stron stworzyłem sobie piekny zestaw klas służący do generowania i walidacji formlarzy. Z perspektywy OOP aż miło mi sie na to patrzy bo to jedna z lepszych rzeczy jaka zobiłem.

Mam zestaw klas Form_Select, Form_TextBox itd. (co robią nie będę tłumaczył bo to oczywste).
Służą one do tego aby do obiektu klasy Form_Form (reprezentującej formularz) dodać odpowiednie pola.
Form_Form jest kontenerem dla obiektów klas dziedziczących po klasie Form_Pole (takich jak wymieniony wcześniej Form_Select etc.). Każda klasa reprezentująca pole formularza przyjmuje też obiekt odpowiadający za walidację pola, np. Waidacja_IntegerDodatnie, Walidacja_StringWymagane, Walidacja_Godzina. Te obiekty są odpowiedzialne za to aby to co user wpisze w pole było tym co ma wpisać.

Następnie formularz jest wyświetlany przez wywołanie jego metody construct(). Tworzy ona podstawowy szkielet html i wywołuje metodę construct() dla wszystkich obiektów reprezentujących pola tak aby się wyświetliły w formularzu.

Kiedy user wypełni formularz i go wyśle tworzony jest znowu jego obiekt aby go zwalidować metodą waliduj(). Zwraca ona true jęli formularz był wypełniony prawidłowo.

Jak widać obiekt formularza jest tworzony dwukrotnie (raz aby go wyświetliś i drugi aby zwalidować).
Stworzyłem więc metodę prywatną w module aby generowała odpowiedni obiekt klasy Form_Form (bo po co kod kopiować).

I teraz niech mi ktoś powie gdzie ja mam ja umieścić uwzględniając wzorzec MVC?

a) czemu nie w akcji?
bo pomimo że Form_Form zawiera metodę waliduj(), która jest odpowiednia dla akcji to zawiera metodę construct(), która wyświetla formularz.

(IMG:http://forum.php.pl/style_emoticons/default/cool.gif) czemu nie w widoku?
bo pomimo że Form_Form zawiera metodę construct(), która jest odpowiednia dla widoku to zawiera metodę waliduj(), która waliduje formularz.

c) czemu nie w modelu?
bo pomimo, że do wygenerowania formularza potrzebne są informacje z bazy danych (np. lista kategorii, do których może należeć dodawany artykuł) to są tez tam metody construct() i waliduj(), które są odpowiednie dla widoku i akcji.

I co z tym fantem zrobić?
Wszystko spełnia zasady dotyczące tego co mówią podręczniki uczące OOP. Wszystko jest zgodne ze zdrowym rozsądkiem (przynajmniej moim) i wszystkiego sie wygodnie używa. Tylko do MVC jakoś tak daleko... no i to, że praktycznie za każdym wywołaniem skryptu trzeba includować dużo tysięcy linii kodu.

Gdyby ktoś miał pomysł jak rozwiązać mój dylemat z formularzami to bardzo prosze o pomoc.
Tym, którzy doczytali do końca gratuluję.

[Sh4dow]

Moje rozwiazanie działające od jakiegos czasu dosc wygodne, tylko nameczyłem sie zeby wszystko chodziło poprawnie

Dynamiczny formularz składa sie z 2 tablic w bazie danych
Pierwsza zawieraz dane o formularzu, druga zawiera dane formularza wpisane przez usera dla jakiegos ID naprzyklad dla user_id.
aby wygenerowac formularz potrzebujesz

1. Identyfikator, wystarczy ID
2. Opis, moze byc nazwa przy polu formularza, ale nie koniecznie, zalezy jak ci pasuje
3. dane o validacji, string, int, select, dir() (to ostatnie to zdefiniowana funkcja do walidacji oraz do tworzenia danych dla pol np.select)
4. default_value, czyli defaultowa wartosc pola jesli jest nie wypełnione lub aby przy dodawaniu nowego elementu przez formularz była jakaś wartość juz dodana, dla typu walidacji rexp albo date mozna wpisac wyzazenia okreslające wyrazenie regularne lub format dat, dla pola select mozna pisac poprostu uproszczona tablice z kluczami i wartosciami dla rozwijalnych menu lub radio butonów
5. flaga określająca czy pole jest wymagane i bez jego poprawnego wypełnienia zwracamy błąd/wyjątek
6. przy stringach lub intach mozna dodac pole o ich długości ale to zalezy jak komu wygodnie

druga tablica to proste

1. user_id
2. form_field_id
3. form_field_value

sa dwie metody publiczne, jedna pobiera dane do generowania formularza dla wybranych ID lub dla wszystkich pól.
Wewnatrz metody prywatne pobieraja dane z tablic, parsuja wszystkie dane tworzac konkretna tablice. Druga metoda do pobierania danych dla danego user_id oraz dla wybranych lub wszystkich ID formularza.
Roznica miedzy tablicami jest taka ze druga ma wiecej o 2 pola, 'value' oraz 'real_value' pola roznia sie wtedy gdzi chodzi o pola typu select gdzie w tablicy łączonej mamy klucz tablicy z pola default_value, wtedy klucz 'real_value' posiada wartosc dla klucza który jest podany w polu 'default_value'. chyba zagmatwałem wiec juz tłumacze na przykładzie
dane tablicy łączonej:

Kod

user_id | form_field_id | form_field_value
       1|              1|                1

tablica z danymi formularza

Kod

id | name | validate | default_value | require | lenght
1 | 'test' | 'select' | 1 => 'test1';2 => 'test2';3 => 'test3'| 1 | null

metoda zwraca wartosci dla value => 1 a dla 'real_value' => 'test1'
oczywiscie musisz sie trzymac jakis standardów jakie sobie ustalisz, wtedy nie powinno byc problemów.

Drugą częścią jest jakiś moduł/funkcja w widoku która bedzie generowac z tej tablicy gotowy formularz. Ja wykonałem funkcje w smarty, gdzie podaje praktycznie 2 parametry, jeden to dane do wygenerowania pola, drugi parametr to flaga błędu, słuzy jedynie do graficznego zaznaczenia bledu, ktora jest nie wymagana wszedzie.

Trzeci element układanki to metoda Walidująca. Sa dwa sposoby, jeden to podac nazwe tablicy _POST w ktorej znajduja sie wysłane formularze, lub tez przekazac juz bezposrednio tablice. Podajesz tablice ID'ków ktore maja być poddane walidacji. Po walidacji otrzymujesz true lub false. Jesli true, uzywasz specjalnej metody ktora zwraca tablice ktora masz pozniej zapisac. Jesli masz false to masz metode zwracającą flagi dla ID'ków które sa błęde, oraz metode która zwróci ci tablice do generowania formularza z danymi ktore wpisal użytkownik.

To sa główne założenia całego obiektu, lub obiektów. Sposob walidacji, sprawdzania itd to kazdy ma swoje sposoby. To jest jeden, w miare uniwersalny sposob na walidacje, generowanie i ogolna obsluge takich formularzy. Odpowiedni panel moze zautomatyzowac ci do maxymum tworzenie generowanie i walidacje formularzy. Wszystko zalezy od tego kto co chce.
Zalety to mozliwosc definiowania gotowych metod walidujących, np gotowymi validacjami moga byc url, email, zip_code (jako kod pocztowy). Dodanie pola do formularza do dodanie kolejnego ID przy pobieraniu danych. Mozna tworzyc grupy pól, mozna dodac kolumne z opisem, komunikatem w przypadku błędu. Mozna generowac komunikat błędu na podstawie pola walidacji.
Wszystko w jednym. Okreslac ID'ki dla formularza, jesli akcja ma walidowac przekazujesz to do walidacji, jesli poprawnie zapis, jesli nie zrwacasz tablice do ponownego generowania. Jesli wyswietlasz formularz pobieraz dane dla formularza lub z tymi samymi idekami pobieraz dane dla danego powiedzmy user_id.

Tutaj problem nie dotyczy modelu MVC ale proby implementacji odpowiedniego rozwiązania.. Takie jest moje zdanie i sposob rozwiazanie tego powyzej. (IMG:http://forum.php.pl/style_emoticons/default/guitar.gif)