[klasa] Former 1.0.0 Opcje

[Bastion]

Witam, dziś prezentuję kolejną klase z serii class5.* do generowania formularzy. Formy generuje na zasadzie skórek (wymagana klasa class5.Chameleon), sprawdza poprawności wprowadzania danych (strict oraz rules : example04) - narazie jest to tylko minimalna i maksymalna dlugosc pola oraz validacja adresu email (przyjmuje wszelkie propozcyje odnosnie validatorow pol). Poniewaz jest to wersja inicjacyjna 1.0.0 - sa pewnie niedociagniecia i jakies braki - niemniej mozna juz na tym pracowac (tak mysle)

Skąd można pobrać : => 'text',
'title' => 'Imię',
'description' => 'W tym polu należy podać swoje imię.',
'name' => 'firstname',
'require' => true);

$field2 = array('_type' => 'text',
'title' => 'Nazwisko',
'description' => 'W tym polu należy podać swoje nazwisko.',
'name' => 'surname',
'require' => true);

$field3 = array('_type' => 'password',
'title' => 'Hasło',
'description' => 'Twoje aktualne hasło.',
'name' => 'pass');

$field9 = array('_type' => 'button',
'name' => 'przycisk',
'value' => 'Wykonaj');


$form1 -> add_element($field1);
$form1 -> add_element($field2);
$form1 -> add_element($field3);
$form1 -> add_element($field9);

if (!($form1 -> passed()))
{
$form1 -> display();
$form1 -> display_errors();
} else
{
print '<pre>';
print_r ($form1 -> get_values());
print '</pre>';
}

readfile('footer.htm');

?>

[splatch]

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.