![]() |
![]() |
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Bastion @ 2006-03-01 21:41:49) splatch - dlaczego sie nie przyda ? Nie przyda się dlatego, że jest to komponent wymuszający określoną budowę aplikacji, uniemożliwia podział kodu, ponieważ wszystko zaciemnia i miesza. Jeśli korzystasz z gotowego rozwiązana (powiedzmy Symfony) to ad 1. masz już komponenty do formularzy ad 2. nie dasz rady wpiąć Formera we framework tak szybko jak byś chciał Jeśli piszesz aplikację od nowa musisz umieszczać logikę biznesową z prezentacyjną w tym samym pliku bądź bardzo blisko - jesteś ograniczony do warunku Former::passwd(). To nie jest najwygodniejsze. Sam byłem zmuszony w jednym projekcie korzystać z pakietu PEAR::QuickForm i mile tego nie wspominam.. Słowem mieszanie kodu prezentacji (jakim bez wątpienia jest formularz) z logiką biznesową (bo z otrzymanymi danymi coś chcesz zrobić) to nie jest dobre rozwiązanie. Połączenie walidacji z kodem prezentacji niesie korzyści ale i wady - gdy pojawi się zmiana w bazie danych zamiast zmniejszyć czy powiększyć samo ograniczenie validatora wracasz do kodu php. W mojavi (i pochodnych), strutsie i zapewne wielu innych rozwiązaniach których nie znam dąży się do wydzielenia walidacji w jedno miejsce - do oddzielnego pliku konfiguracyjnego. Dążąc do porządku w kodzie separuje się takie rzeczy, to znaczy generacja formularza to jedno, walidacja to drugie a wykonanie logiki biznesowej to trzecie. W Springu jest od tego SimpleFormController i Validatory. Jeśli taka klasa ma zdobyć powodzenie to tylko w połączeniu z dobrym systemem szablonów. Przykładem może być struts ze swoimi taglibami, którymi można w ładny sposób wyśwetlić zawartość beana ActionErrors bądź pojedyńczy błąd. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 01:02 |