[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]

Przy korzystaniu z szablonów niestety klasa na nic się nie przyda. Ja osobiście mam napisane 2 komponenty do smarty, które są zintegrowane z mojavi, całość działa półautomatycznie.

[Bastion]

splatch - dlaczego sie nie przyda ?

[nospor]

Ja narazie na szybko. Jedna rzecz mi sie rzuca w oczy i ona mi sie nie podoba.
Masz przygotowane szablony dla róznych rzeczy: form_open, form_close, input, button. Rozumiem, ze kazdy element danego typu zawsze bedzie w tym szablonie?
A co jesli danego inputa bede chcial w innym szablonie? Wszystkie w tym samym ale akurat jeden w innym?

Widze, ze u ciebie szablon na pola to pelno kodu html, tr, td i inne. rety. Rozumiem, że nie mozna samemu sobie definiowac dowolnie wygladu i rozmieszczenia pól. Zdefinuije sie tylko tabelaryczny szablon i leci wszystko na jedno kopyto. Osobiscie uwazam to za duzo wadę, wg. mnie jest to malo uniwersalne rozwiązanie.

No i brakuje walidacji js (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Przy korzystaniu z szablonów niestety klasa na nic się nie przyda

Tu sie mylisz. Ja uzywam rownież smarty i bardzo dobrze mam podczepioną do tego klasę (wlasnej produkcji). Obie rzeczy sie nie gryzą. Wręcz przeciwnie - dobrze ze sobą wspoldzialają

[Bastion]

Masz przygotowane szablony dla róznych rzeczy: form_open, form_close, input, button. Rozumiem, ze kazdy element danego typu zawsze bedzie w tym szablonie?
A co jesli danego inputa bede chcial w innym szablonie? Wszystkie w tym samym ale akurat jeden w innym?

Ciekawy pomysl, ale zastanawiam sie czy bedzie mial "branie". Zawsze moge dorobic parametr

Kod

$element(array('template' => 'moj_szablon.tpl') ....... );

Niemniej trzeba sie nad tym zastanowic (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Widze, ze u ciebie szablon na pola to pelno kodu html, tr, td i inne. rety. Rozumiem, że nie mozna samemu sobie definiowac dowolnie wygladu i rozmieszczenia pól. Zdefinuije sie tylko tabelaryczny szablon i leci wszystko na jedno kopyto. Osobiscie uwazam to za duzo wadę, wg. mnie jest to malo uniwersalne rozwiązanie.

Skorke mozna sobie zrobic na divach, a kazdemu elementowi przypisac inna klase poprzez parametr

Kod

$element(array('style' => 'styl') ....... );

... wiec chyba nie byloby problemu.

No i brakuje walidacji js winksmiley.jpg

YYy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) kiedy nie uzylem tam js (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ?

[aleksander]

ihmo bardziej obiektowo jest
$oForm = addElement( new Input( array( type itd ) ) ); ale to juz zalezy od kodera;]

co z definiowaniem styli klas i w ogole atrybutów dla pól?

validatory:
not null
only numbers
only letters
only numbers and letters
only special chars
min dlugosc ( z tego co pamietam max dlugosc jest juz jako atrybut)

w ogole mi sie nie podoba dodawanie pol u Ciebie no ale dobra. zobaczymy jak to rozwiniesz

[nospor]

no dobra. te divy i klasa moze to i rozwiąze problem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

YYy  kiedy nie uzylem tam js  ?

yyy, nie rozumiem? Mowie ci ze nie ma walidacji js.
http://www.vertis.com.pl/demo/former/examples/example04.php

edit: po otrzymaniu PW wyjasniam:
js - java script (skrypt, ktory wykonuje sie po stronie klienta)
nie ma u ciebie walidacji js, czyli ze wszystko jest walidowane po stronie serwera w php.Czyli zeby zostalo zwalidowane, musi zostac wyslane na serwer i jesli jest źle to strona na nowo sie musi ladowac.
Dla ulatwienia zycia ludkom wprowadza sie walidacje js, ktora to zapobiega wyslaniu formularza, jesli są w nim bledy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Bastion]

co z definiowaniem styli klas i w ogole atrybutów dla pól?

Mozna to doac poprzez paremetr 'style' badz podawac nazwe atrybutow jako klucz, jest tam w przykladach. Na poczatek chcialem ograniczyc dodawanie parametrow do tych ktore sa "akceptowane" przez klase, tak aby uzytkownik nie podal nieistniejacego parametru.

validatory:
not null
only numbers
only letters
only numbers and letters
only special chars
min dlugosc ( z tego co pamietam max dlugosc jest juz jako atrybut)

bedzie dodane (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

w ogole mi sie nie podoba dodawanie pol u Ciebie no ale dobra. zobaczymy jak to rozwiniesz

Planuje jeszcze jedna metode dowania pol poprzez jedna tablice zawierajace wszystkie elementy.
add_elements($array);

[aleksander]

u mnie generowanie formularza wyglada tak:

[PHP] pobierz, plaintext 
<?php
$oForm = new Form( array( 'name' => 'test', 'action' => '#', 'method' => 'post') );
$oFieldset = new Fieldset( array( 'style' => '-moz-border-radius: 6px;' ) );
$oLegend = new Legend();
$oLegend->setText( 'Logowanie' );
$oFieldset->addElement( $oLegend );
 
$oLoginLabel = new Label( array( 'for' => 'login' ) );
$oLoginLabel->setText( 'Login:' );
$oFieldset->addElement( $oLoginLabel );
 
$oLogin = new Input( array( 'id' => 'login', 'name' => 'login', 'type' => 'text' ) );
$oForm->addPlugin( new IsNotNullRule( $oLogin ) );
$oFieldset->addElement( $oLogin );
 
$oPassLabel = new Label( array( 'for' => 'password' ) );
$oPassLabel->setText( 'Haso:' );
$oFieldset->addElement( $oPassLabel );
 
$oPass = new Input( array( 'id' => 'password', 'name' => 'pass', 'type' => 'text' ) );
$oForm->addPlugin( new IsNotNullRule( $oPass ) );
$oForm->addPlugin( new MD5Hash( $oPass ) );
$oFieldset->addElement( $oPass );
 
$oFieldset->addElement( new Input( array( 'id' => 'submitBtn', 'type' => 'submit', 'value' => 'Wyslij' ) ) );
$oForm->addElement( $oFieldset );
$sContent = '';
if( $oContext->getRequest()->getMethod() == IHttpRequest::POST )
{
	echo $oForm->processPlugins() ? 'formularz wypelniony poprawnie' : 'formularz wypeniony niepoprawnie.';
}
$oContext->getResponse()->addContent( $sContent . $oForm->getCode() );
?>
[PHP] pobierz, plaintext 

moze wydaje sie ze duzo kodu ale po pierwsze masz trutaj tez fieldset i labele po drugie dosyc wygodnie sie pisze

Na poczatek chcialem ograniczyc dodawanie parametrow do tych ktore sa "akceptowane" przez klase, tak aby uzytkownik nie podal nieistniejacego parametru.

ja nawet to zaimplementowałem i wyszło że wyrzera pamięc (uzywalem array_diff) wiec nie warto;]

[Bastion]

aleksander: w jakim celu uzywasz labele ? tzn co to daje ? czy moglbys gdzies wystawic taki dzialajacy form ?

[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.