![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 25.11.2005 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Witam
Mam trzy pytania odnośnie wzorca MVC, byłbym wdzięczny za wszelkie wskazówki. 1) Co powinno znaleźć się w modelu? Rozumiem że np. wszelkie funkcje dotyczące konretnych zadań nie związanych z wyświetlaniem danych. Czyli w takim razie klasa do zarządzania użytkownikami będzie modelem? 2) Filtracja i walidacja danych wejściowych, które mają mieć jakiś określony typ, powinna się odbywać w kontrolerze czy modelu? Nie mówię tutaj o zapisie do bazy/pliku, ta filtracja jest w osobnym DAO. 3) Wielojęzyczność strony mam rozumieć powinna być w zaimplementowana gdzieś w elemencie widoku? -------------------- Humans cannot create from nothingness, humans cannot accomplish anything without holding on to something, humans are not gods.
PLD Linux AC / Eclipse 3.2.1 / Firefox 2.0 |
|
|
![]()
Post
#2
|
|
![]() Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
1. Model to dane oraz czynności wykonywane na nich, czyli po ludzku - symulacja przedstawianego środowiska. Nigdy nie starałem się odwzorować modelu na klasy, bo jest to dla mnie pojęcie abstrakcyjne...
2. Najczęściej dane zostają filtrowane w filtrach przed łańcuchem akcji. Poszukaj czegoś o wzorcu Intercepting Filter, to wyjaśni Ci się sprawa ![]() 3. Tak powinno być, lecz niektóre elementy takie jak wersje językowe artykułów są pobierane przed wywołaniem widoku, więc pobranie odpowiedniej wersji artykułu, newsa czy czegokolwiek innego, nie przeszkadza w realizowaniu założeń wzorca. Aczkolwiek elementy interfejsu powinny być tłumaczone w widoku... -------------------- |
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 25.11.2005 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Ludvik) 2. Najczęściej dane zostają filtrowane w filtrach przed łańcuchem akcji. Poszukaj czegoś o wzorcu Intercepting Filter, to wyjaśni Ci się sprawa No tak. Takie filtrowanie sprawdzi się przy autoryzacji, wybieraniu lokalizaji użytkownika etc. Ale czy to odpowiednie miejsce żeby sprawdzać czy w polu formularza został wpisany poprawny adres email bądź pole nie zawiera tagów html? Ten post edytował raikou 25.09.2006, 16:58:00 -------------------- Humans cannot create from nothingness, humans cannot accomplish anything without holding on to something, humans are not gods.
PLD Linux AC / Eclipse 3.2.1 / Firefox 2.0 |
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 1 597 Pomógł: 30 Dołączył: 19.02.2003 Skąd: Tychy Ostrzeżenie: (0%) ![]() ![]() |
Ja mam w akcji metodę validation(), która właśnie jest odpowiedzalna za walidację.
-------------------- Zapraszam na mój php blog, tworzenie stron.
|
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 176 Pomógł: 0 Dołączył: 30.11.2004 Ostrzeżenie: (0%) ![]() ![]() |
No tak. Takie filtrowanie sprawdzi się przy autoryzacji, wybieraniu lokalizaji użytkownika etc. Ale czy to odpowiednie miejsce żeby sprawdzać czy w polu formularza został wpisany poprawny adres email bądź pole nie zawiera tagów html? tutaj najlepiej sprawdza się AJAX...lub poprostu DHTML i JS -------------------- |
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 426 Pomógł: 1 Dołączył: 2.10.2005 Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#7
|
|
![]() Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Można dodać filtry wywoływane tylko przed konkretną akcją czy też łańcuchem akcji. Najprościej jednak dodać akcję sprawdzającą te dane przed wywołaniem akcji dodającej je do bazy. W przypadku niepowodzenia zawsze można przekierować kontroler do innej akcji, która wyświetli formularz z zaznaczonymi błędami.
-------------------- |
|
|
![]()
Post
#8
|
|
![]() Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 25.11.2005 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Mimo wszystko raczej zdecyduję się na utoworzenie konretnych obiektów formularzy oraz zawarcie w nich metod sprawdzających poprawność danych. Jeden formularz dla dodawania i edycji newsa, posta etc.
Tworzenie kolejnych akcji w kontrolerze wydaje mi się problematyczne w momencie gdy jest sporo formularzy i każda zmiana w obiekcie widoku (formularz) pociąga za sobą zmiany w kontrolerze (walidacja). Sprawdzanie samym JSem jest może fajne i wygodne ale co jeżeli ktoś prześle dane $_POST używając swojego formularza a nie mojego? Pomijając fakt że PDO wyeliminuje SQL Injection, będę miał bałagan w danych ![]() -------------------- Humans cannot create from nothingness, humans cannot accomplish anything without holding on to something, humans are not gods.
PLD Linux AC / Eclipse 3.2.1 / Firefox 2.0 |
|
|
![]()
Post
#9
|
|
![]() Grupa: Zarejestrowani Postów: 426 Pomógł: 1 Dołączył: 2.10.2005 Ostrzeżenie: (0%) ![]() ![]() |
Niewiem czy opłaca sie tworzyć jeszcze osobne klasy do każdego formularza aby je sparadzić, bo i tak trzeba robić klase widoku, model, kontroler no i by jeszcze klasa form doszła.
Narazie robie wielkie uproszczenie z walidacją:
Jak widać jest to nie estetyczne rozwiązanie. Lepiej stworzyć formularz dzięki xml i napisać jakąś 1 klase sprawdzającą i walidującą pola a na koncu wyświetlenie błędów. |
|
|
![]()
Post
#10
|
|
![]() Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Mimo wszystko raczej zdecyduję się na utoworzenie konretnych obiektów formularzy oraz zawarcie w nich metod sprawdzających poprawność danych. Jeden formularz dla dodawania i edycji newsa, posta etc. Tworzenie kolejnych akcji w kontrolerze wydaje mi się problematyczne w momencie gdy jest sporo formularzy i każda zmiana w obiekcie widoku (formularz) pociąga za sobą zmiany w kontrolerze (walidacja). Sprawdzanie samym JSem jest może fajne i wygodne ale co jeżeli ktoś prześle dane $_POST używając swojego formularza a nie mojego? Pomijając fakt że PDO wyeliminuje SQL Injection, będę miał bałagan w danych ![]() Tak, stworzenie systemu obsługi formularzy z walidacją jest najlepszym pomysłem, ale gdzieś trzeba utworzyc instancje tych klas. Najwygodniejszym momentem jak dla mnie jest odpowiednia akcja. Tak czy inaczej trzeba gdzieś potworzyć te obiekty, a akcja będzie jedynym miejscem, w którym to nastąpi, a co za tym idzie, jedynym kawałkiem kodu, który trzeba będzie poprawić przy zmianie widoku. To nie są chyba duże zależności ![]() Jeżeli masz jakieś schematy tworzenia formularzy (xml czy coś w tym stylu), to obiekty pewnie stworzysz dynamicznie w filtrach. -------------------- |
|
|
![]()
Post
#11
|
|
Grupa: Zarejestrowani Postów: 31 Pomógł: 0 Dołączył: 2.06.2006 Ostrzeżenie: (0%) ![]() ![]() |
To ja zaprezentuje jak obsługa formularzy wygląda u mnie, na przykładzie dodawania nowego użytkownika
A w widoku opieram się na funkcjach formularza: form, error, isError, field. |
|
|
![]()
Post
#12
|
|
![]() Grupa: Zarejestrowani Postów: 800 Pomógł: 0 Dołączył: 26.11.2005 Skąd: Nowy Sącz Ostrzeżenie: (0%) ![]() ![]() |
Ja tutaj wcisnę swoje pytanie z zupełnie innej beczki. Gdzie i kiedy najlepiej tworzy egzemplarz klasy request ? Czy do niej wsadzać parameters z path_info ?
-------------------- Jah Music Is On My Mind !
|
|
|
![]()
Post
#13
|
|
![]() Grupa: Moderatorzy Postów: 1 566 Pomógł: 37 Dołączył: 14.05.2003 Skąd: Kraków ![]() |
Instancja requesta tworzona jest w kontrollerze. To ona odpowiada za dane wejściowe do systemu. Ona sprawdza dane czy są poprawne ($_GET). To poprzez nią pobierasz dane z tablicy POST.
Także nie ma co zapychać go parametrami z path_info, stwórz sobie do tego ParameterHolder. ![]() |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 19.06.2024 - 04:43 |