[OO] Formularze a obiekty Opcje

[scanner]

Dziaiaj podczas dyskusji z PMadejem wynikł temat obiektowej obsługi formularzy. Zaświtał mi w głowie taki schemacik, jaki podaję niżej. Oczywiscie nie gwarantuję, ze zadziała - ale myślę, że wystarczająco obrazuje mój tok myśłenia. Co sądzicie do tagiego podejścia do tematu walidacji dancy hz formularzy?

BTW: w kodzie wielu rzeczy nie ma, ale nie w tym sęk...
[php:1:5d9c559937]<?php
class Form
{
var $arrFormElements = NULL;
function Form()
{
$this->FormElements = array();
}

function CreateField( $strName )
{
$this->arrFormElements[$strFieldName] = new FormField();
}
}
class FormField
{
var $strName = '';
var $strType = '';
var $mixData = '';
var $blnRequired = false;
var $blnValid = false;
var $blnPattern = NULL;
var $mixPatternName = '';
var $arrErrors = NULL;

function FormField()
{
$this->arrErrors = array();
}

function Create()
{
$smarty->display( 'form_elements/'.$this->strFieldType.'.tpl' );
/**
* Zakładamy, ze mamy teplatesy typu: textarea, input, button itp.
*/
}

function ValidatePattern( )
{
if( $this->blnRequired )
{
$this->blnValid = !is_empty( $this->mixData );
if( !$this->blnValid )
{
$this->arrErrors[] = 'Must be filled';
}
}
if( !is_null( $this->$blnPattern ) )
{
$this->blnValid = preg_match($this->$blnPattern, $this->$blnData);
if( !$this->blnValid )
{
$this->arrErrors[] = 'Must be corrected '.$this->strPatternName.' value!';
}

}
}
}

/**
* Example of use
*/
$Form = new Form();
$Form->CreateField( 'pkwiu', true );
$Form->arrFormElements['pkwiu']->strType = 'input_text';
$Form->arrFormElements['pkwiu']->strData = $_POST['pkwiu'];
$Form->arrFormElements['pkwiu']->strPattern = '([0-9]{2}.[0-9]{1,2}.[0-9]{1,2}-[0-9]{1,2}.[0-9]{1,2})';
$Form->arrFormElements['pkwiu']->strPatternName = 'PKWiU';

$Form->arrFormElements['pkwiu']->ValidatePattern();
if( !$Form->arrFormElements['pkwiu']->blnValid )
{
$Form->arrFormElements['pkwiu']->Create();
foreach( $Form->arrFormElements['pkwiu']->arrErrors as $strError )
{
echo '<br />'.$strError;
}
}
?>
[/php:1:5d9c559937]

[halfik]

hmmm... interesujące, sam nigdy się nie zastanawiałem, że można sprawe w OOP jedną klasą rozwiązać... jak ktoś sprawdzi jakby to w praktyce wyglądało, to wówczas można by w pełni ocenić pomysł, bo wygląda na to, że można sporo czasu oszczedzić na formach...

[scanner]

W wolnych chwilach sponbuję rozbudowac to w coś większego.
Oczywiscie miłoby było jakbyście podali jakieś wskazówki i pomysły - może z tego wyjść coś ciekawego.

[PMadej]

W wolnych chwilach sponbuję rozbudowac to w coś większego.
Oczywiscie miłoby było jakbyście podali jakieś wskazówki i pomysły - może z tego wyjść coś ciekawego.

scanner jako, że jestem po części współtwórcą tego pomysłu postaram się przez święta coś też napisać i zamieszczę tutaj wyniki moich rozważań po świętach.

OT: to mój ostatni post przed wyjazdem do rodzinki, więc życzę wszystkim wesołych i rodzinnych świąt, smacznego jajka i wesołego zajączka

[DeyV]

Sądzę, że to bardzo dobry pomysł.
Już jakiś czas temu zastanawaiłem się nad takim systemem wykorzystującym system szablonów, jednak 'nadmiar wolnego czasu' zmusił mnie do pozostania przy tym co mam teraz, czyli formularze w oop, ale nie współpracujące z smarty.

Jednak ostatnio bardzo ucieszyła mnie informacja, że system z którego korzystam wciąż jest rozwijany.
Co więcej - pojawiła się w nim, może nie pełna, ale jednak, możliwość łączenia formularzy przygotowanych przez niego właśnnie z systemami teplates. Co prawda nie wiem jeszcze jak to się sprawdza w praktyce - wiem jednak, że sam system zaoszczędził mi bardzo wiele pracy.

http://pof.sourceforge.net/
Zawiera również kilka ciekawych pomysłów, z których warto by chyba było skorzytać przy rozwoju tego projektu.

[hawk]

Hmm, ogólnie to co pokazuje Scanner i to co jest pod linkiem podanym przez DeyVa podoba mi się. Ale... POF idzie chyba w złą stronę. Ja bym chciał system, w którym cały layout formularza pisany jest normalnie, w tym samym szablonie w którym reszta strony. Bo żaden system, który sam buduje formularz, nie przewidzi wszystkich możliwości HTMLa. No i nie należy mieszać HTMLa z kodem. Już to co proponuje Scanner jest lepsze, ale też ma wady: a co jak nie chcę używać Smarty? a co jak na jednej stronie pole input ma wyglądać inaczej niż na drugiej i z jednego szablonu nie da rady ich wygenerować?

Więc ja bym sobie wyobrażał coś takiego:
1) HTML piszemy sobie normalnie, jak się nam podoba.
2) Jakiś FormController w kodzie php jest konfigurowany (zapodajemy mu, jakie pola ma nasz formularz itd) - nawet lepiej będzie jak tą konfigurację odczyta sobie z pliku, niż gdybyśmy mieli ją hard-coded w php
3) Taka konfiguracja zawiera oczywiście przede wszystkim reguły walidacji formularza
4) Na stronie z samym formularzem, FormController wstawia do odpowiednich pól wartości, jeżeli te wartości przyszły w $_POST, i sygnalizuje błędy; może też automatyczie generować JS walidującego wstępnie formularz
5) Na stronie docelowej FormController robi pełną walidację i w razie błędów przekierowuje z powrotem na formularz (jak? nie wiem, raczej nie przez przeglądarkę) - tutaj widać że potrzebny jest osobny plik z konfiguracją bo obsługa formualrza "rozciąga się" przynajmniej na 2 strony
6) W HTML powinny być specjalne znaczniki pozwalające wstawić info o błędach w formularzu - jeżeli nie robimy żadnych założeń co do systemu szablonów to pozostaje chyba tylko JS i DOM, w przeciwnym razie coś jak rozwiązanie w WACT

[hawk]

Jeszcze dodam że walidacja powinna być zrobiona zgodnie ze wzorcem Strategy (czy Command? nieważne). Dlaczego tylko regexp? A jak chcę np zwalidować że pole zawiera liczbę z przedziału od-do? Niech każde pole może mieć reguły walidacyjne -> obiekty. A taki obiekt może wykonywać regexpa lub robić coś innego. System się trochę więcej komplikuje ale mamy pełną elastyczność.
Chyba system Mojavi miał takie walidatory w postaci obiektów...

[scanner]

To co ja proponuję to tylko szkic, który powstał w chwili, gdy z PMadejem rozmawialiśmy i walidacji danych z formularza. Pomyślałem w tym momencie o tym, że formularz to też obiekt, którefgo jedną z własności jest pole, które też jest obiektem.

Powyższy kod powstał w sumie w 45 minut i jst tylko szkicem. Jest tam tylko jedna metoda walidacyjna ale po odpowiedniej modyfikacji metody można dodawać - zacząc trzeba od budowy obiektu "FormField".
tak samo użycie linijki ze smarty bylo tylko przykładem. W praktyce trzeba by to rozwiązać inaczej. Zresztą całe rysowanie formularza trzeba zmienić.

Wydaje mi się, że możńa nieco zapomnieć o generowaniu formularza - ważniejsze jest przechwytywanie danych i ich walidacja. Tak jak piszesz hawk, generowanie pojedyńczych pól raczejnie ma sensu. Lepszym chyba byłoby:
1. Genrujemy formularz "klasycznie"
2. Tworzymy tablicę z nazw pół i ich wartości
3. Dodajemy to tablicy typy walidacji dla okreslonego pola
4. Walidujemy
5. Jeśli coś jest nie tak Generujemy formularz jak w 1 - assignująć tablicę błędów.
Pisane z palca:
[php:1:2efa755e74]<?php
$Form = new FormValidator( $_POST );
$Form->Field['login']->CheckList['required'] = true;
$Form->Field['login']->CheckList['minLength'] = 3;
$Form->Field['pass']->CheckList['requred'] = true;
$Form->Field['pas2']->CheckList['requred'] = true;
$Form->Field['pass']->CheckList['compare'] = $Form->Field['pas2'];

$isFormValid = $Form->ValidateFields();
?>[/php:1:2efa755e74] a ValidateFields() wywołuje metody prywatne, takie jak:[php:1:2efa755e74]<?php
function _required( $strFieldName )
{
if( !isset($this->Field[$strFieldName]))
{
$this->Field[$strFieldName]->Errors[] = Lang::Get('EmptyFormField');
return false;
}
return true;
}
?>[/php:1:2efa755e74]

[halfik]

2. Tworzymy tablicę z nazw pół i ich wartości

A masz jakiś pomysł jak taką tablicę wygenerowac automatyczni na podstawie zapodanego szablonu? Bo można by przeszukać szablon np. szukamy forma gdzie name="logowanie", pozbierać dane o typach pól... ale co dalej? jak potworzyć do odp. pół validacje, żeby nie robić tego ręcznie w kodzie wywołując metodę i podając jej co trzeba? Może wprowadzić w samym szablonie jakieś specjalne hmm... bo ja wiem tagi z inf. które później odp. metoda by tylko wyciągała?

tak... leniwy jestem i dlatego kombinuje jak to zrobić, żeby ta klasa była niezawodna i sama wszsytko potrafiła zrobić.

[DeyV]

przeszukiwanie szablony byłoby, IMHO, bardzo złym rozwiązaniem.
Znacznie lepiej byłoby przygotowac osobny plik, zawierający tablicę z danymi dotyczącymi formularzy które pojawią się na danej stronie.
Tablica ta zawierałaby informacje o tym, jakie są tam pola, jak się nazywają, jakiego są typu (select, input text itp. ) oraz jak się mają walidować.
Uruchomienie formularza polegałby na załadowaniu takiej tablicy, i w zależności do tego, czy w post przyszły jakieś dane i czy są poprawne - wyświetlany byłby formularz, albo wykonywna jakaś inna akcja np. wyświetlająca wyniki.

A jak to wykorzystać w szablonie?
W przypadku smarty - można by było udsępnić do szablonu każdy z obiektów, a w samym szablonie wykorzystywać atrybuty i metody takiego obiektu, w celu wyświetlenia wartości pola, jego opisu, albo komunikatu walidacyjnego.
Oczywiście może to również przesyłać w postaci tablicy.

[Ace]

a nie latwiej jest...
klasa generujaca formularz zwraca jakies dane w wyniku, a potem wrzucamy ten wyni do smarty,
[php:1:0be2a603aa]<?php
$smarty->assign('Form1',$formFields);
?>[/php:1:0be2a603aa]
a potem w szablonie .tpl

Kod

{$Form1}

? nie latwiej ? nie wiem w jakis sposob maja sie przekazywac obiekty, a po co ? latwiej chyba zwrocic dane ktore zostana przypisane do szablonu. Tylko zostaje problem w jakim stylu generuja sie Formularze ( kolorystyka. jakie tabele ) ale do tego mozna by bylo przygotowac oddzielne szablony tpl. Oczywiscie bazowo klasa generujaca formularz musi ich urzywac. Ale to i tak pozostaje klopotliwe, gdyz jesli chcemy miec 2 rozne formularze na stronie ( stylowo, kolorystycznie ) to musimy tworzyc 2 serje plikow do formularza.

[halfik]

heh, wygląda na to, ze należałoby jednak wszsytko zostawic wew. klasy, łącznie z kolorsytyką itd. porobić odpowiednie metody, które na rzecz formularza będą tworzyły odp. CSSa - w ten sposób możeby na jednej stronie mieć wiele różnych stylowo formów. A skoro już wszsytko miałoby być w klasie to i ta tablica z nazwami pól itd. bedzie na wejścei do jakiejś metody, tablice naturalnie można by definiować w zew. pliku, a potem go podczepić i podsunąć na wejście.

P.S scanner: pewnie jesteś nie mniej zapracowany niż inni, ale jako współautor pomysłu: może zrobiłbyś beta wersję (taką już działającą), udostępnił i każdy mógłby zacząć kombinować co i gdzie zmienić, ulepszyć, dodać itd. ? Bo takie rozważania "na sucho" nie wiele dają jak nie ma na czym oprzeć teorii...

[scanner]

Musże przemyśleć kwestie czy stawiac na uniwersalność i pełna automatyke, czy pozostawić coś programiście do ręcznego opracowania. Przez świąte mnie nie będzie - pomyślę nad tematem w tym czasie. Może po powrocie pokażę jakiś przykładowy dziąłający kod.

[DeyV]

Tu pojawi się problem potrzeb.
Bo o ile np. takie POF jest w pełni zautomatyzowane, i odpowiada za całość designu formularza.
TO się sprawdza ... w przypadku systemów, gdzie dokłądny wygląd formularza nie ma dla nas większego znaczenia, czyli wszelkie panele administracyjne itp.

Jednak w sytuacji gdy chcemy wykorzystać ten system do tworzenia elementów stron, to - niestety - pojawia się problem. Bo tu wymagana jest znacznie większa elastyczność. W takiej sytuacji znacznie łatwiej jest skonfigurować styl, wygląd i rozmieszczenie z samego poziomu tempklatesa, niż narzucać go z poziomu skrytpu.

Jak to połączyć?

[halfik]

hmm... chyba nie ma wyjścia i trzeba dobrać się np. do SMARTY i w nim wszsytko zrobić. Bo faktycznie musimy mieć możliwość ustalania wyglądu itd., ale bez sensu byłoby mieszanie warstwy prezentacyjnej z logiczną, a skoro już są SMARTY, to można by w nich pomieszać... nie wiem... przemyślcie sprawę.

nie, to bez sensu... a może by tak dodać w clasie funkcję, która na wejście chce dostać plik CSS i wszystko byłoby w tym pliczku (to odnośnie samych kolorków)? Tylko, że teraz wszędzie mielibyśmy jeden design dla formów... Ew. można by rozbudować CSSa o np. InputType1 i jakoś inf. obiekt, o którego styla nam chodzi.

[PMadej]

no i przyszla kolej na moje swiateczne wypociny i przemyslenia. To co stworzylem odpowiada za wyswietlanie formularzy i jest nadal wersja rozwojowa ... oparte o schemat scannera. Walidator to jak na razie za skomplikowane dla mnie.
Moje klasy korzystaja z klasy glownej MainClass.inc.php:[php:1:b952a1ed0c]<?php
require_once(ENV_smarty_dir.'Smarty.class.php');
require_once(ENV_adodb_dir.'adodb.inc.php');

class Main
{
var $smarty;
var $adodb;

function Main()
{
//tworzenie obiektu smarty
$this->smarty = new Smarty;

$this->smarty->cache_dir=ENV_cache_dir;
$this->smarty->template_dir=ENV_templates_dir;
$this->smarty->compile_dir=ENV_compile_dir;

//tworzenie obiektu adodb
$this->adodb = ADONewConnection(ENV_db_type);
$this->adodb->SetFetchMode(ADODB_FETCH_NUM);
$this->adodb->connect(ENV_db_server,ENV_db_user,ENV_db_password,ENV_db);

}

}


?>[/php:1:b952a1ed0c]

klasa FormClass.inc:
[php:1:b952a1ed0c]<?
require(ENV_core_dir.'MainClass.inc.php');
class Form extends Main
{
var $arrFormElements = NULL;
var $arrFormHeader = NULL;
function Form($action,$method) //tworzy obiekty i generuje naglowek formularza
{
$this->Main();
$this->arrFormHeader['action']=$action;
$this->arrFormHeader['method']=$method;
$this->smarty->assign('action',$this->arrFormHeader['action']);
$this->smarty->assign('method',$this->arrFormHeader['method']);
$this->smarty->display(ENV_templates_dir.'FormHeader.tpl');
}
//tworzy konkretne pola formularza
function CreateField($type,$name,$value,$required,$fieldpattern)
{

$this->arrFormElements[$name] = new FormField();
$this->arrFormElements[$name]->strFieldName = $name;
$this->arrFormElements[$name]->strFieldType = $type;
$this->arrFormElements[$name]->mixFieldData = $value;
$this->arrFormElements[$name]->blnFieldRequired = $required;
$this->arrFormElements[$name]->blnFieldValid = null;
$this->arrFormElements[$name]->strFieldPattern = $fieldpattern;//'([0-9]{2}.[0-9]{1,2}.[0-9]{1,2}-[0-9]{1,2}.[0-9]{1,2})';
$this->arrFormElements[$name]->Validate();

$this->arrFormElements[$name]->Create();
}
function ShowElements()
{
print ('<pre>');
print_r($this->arrFormElements);
print ('</pre>');
}
}
class FormField extends Main
{
var $strFieldName = '';
var $strFieldType = '';
var $mixFieldData = '';
var $mixFieldPattern = '';
var $blnFieldRequired = false;
var $blnFieldValid = false;
var $blnFieldPattern = NULL;
var $arrFieldErrors = NULL;

function FormField()
{
$this->Main();
$this->arrFieldErrors = array();
}

function Create()
{
$this->smarty->assign('name',$this->strFieldName);
$this->smarty->assign('value',$this->mixFieldData);
$this->smarty->display(ENV_templates_dir.$this->strFieldType.'.tpl' );
/**
* Zakładamy, ze mamy teplatesy typu: textarea, input, button itp.
*/
}
}

?>[/php:1:b952a1ed0c]

i zastosowanie:
[php:1:b952a1ed0c]<?php
require('config.php');
require(ENV_core_dir.'FormClass.inc.php');

$form = new Form($PHP_SELF,'POST');
$form->CreateField('input_text','nazwa','',true,'');
$form->CreateField('input_radio','wybór','opcja 1',false,'');
$form->CreateField('input_radio','wybór','opcja 2',false,'');

$form->CreateField('input_checkbox','check','opcja 1',false,'');
$form->CreateField('input_checkbox','check','opcja 2',false,'');
$form->CreateField('select','select','',false,'');
$form->CreateField('option','','opcja 1',false,'');
$form->CreateField('option','','opcja 2',false,'');
$form->CreateField('option','','opcja 3',false,'');
$form->CreateField('select_end','','',false,'');

$form->CreateField('select','select2','',false,'');

$opcje=array('opcja 1','opcja 2','opcja 3');
$form->CreateField('option2','',$opcje,false,'');
$form->CreateField('select_end','','',false,'');


$form->CreateField('submit','submit','PotwierdĽ',true,'');
$form->CreateField('reset','','usuń informacje',false,'');
//$form->ShowElements();

?>[/php:1:b952a1ed0c]

przykladowy szablon:
[xml:1:b952a1ed0c]
<INPUT type="radio" name="{$name}" value="{$value}">{$value}<br>
[/xml:1:b952a1ed0c]
przy wyswietlaniu napotkalem na ponizsze problemy z dodatkowymi opcjami konkretnych pol i z braku czasu tego nie rozwiazalem:
- opcja checked w polu radio
- rozne value i opis pola dla checkboxa i radio
- opcja multiple dla select'a
- opcja maxlenght dla input text
- rows/cols dla textarea

w kwestii wygladu formularza stosujac ww rozwiazanie w metodzie form() mozemy dodac wlasciwosc stylu i po problemie

[PMadej]

problemy o ktorych wspomnialem na koncu poprzedniego posta sklonily mnie do zmienienia kierunku rozwazan. Tym razem w dyskusji z DeyV'em poruszylismy troche glebiej temat szablonowosci formularzy i problemami z tym zwiazanymi.

POF ma scisle ustalony uklad formularza i wszystko jest w nim strasznie potabelkowane (kazde pole ma swoja tablele, w ktorej jest opis komunikaty bledow, pole itd.). Osobiscie wydaje mi sie ze jest to dobre jesli nie korzystasz z zadnego systemu szablonow, ale gdy chcesz je zastosowac ilosc tabeli wzajemnego ustalania wielkosci polozenia zaczyna sprawiac problemy.

i tu wyszedl pomysl utworzenia biblioteki schematow formularzy (np. tabela 2 kolumny w 1 opisy do pol w 2 pola, lub szablon gdzie opisy do pol sa nad nimi) co o takim rozwiazaniu sadzicie?

doszlismy tez do wniosku ze trzeba dla kazdego typu pola utworzyc osobny szablon pozwalajacy nim zarzadzac (zawierajacy wszystkie mozliwe opcje dla danego pola oraz znacznik class=" ... " dzieki ktoremu bedziemy mogli zarzadzac stylami kazdego z pol osobno)

to na razie chyba tyle czekam na sugestie i wasze opinie

[hawk]

Mi się generalnie nie podoba opcja z generowaniem kodu HTML przez klasę formularzy. Bo to JEST pomieszanie warstwy prezentacji z logiką biznesową.
Jedna osoba robi kod HTML (ew. szablon), druga php, i system musi to skleić do kupy. Nie może być tak, że na stronie wstawiamy wielkie "tutaj będzie nasz formularz", i facet od CSS wysyła facetowi od php maila żeby wpisał w swoim kodzie takie a takie style.

Tylko że aby to zrobić, trzeba albo wbudować to w system szablonów, albo parsować cały HTML przed wywaleniem na ekran. Bo jakiś mechanizm musi znajdować formularze i wstawiać co trzeba.

W dobrym kierunku idzie chyba WACT, bo tam <form> jest - oprócz tego że jest formularzem w HTML - jednym z tagów engine, który rozumie co to jest formularz i jakoś tam łączy z kontrolerem formularzy. Ale to jest wbudowane w silnik szablonów, i nie do użycia np. w Smarty.

Może po prostu nie da się zrobić dobrego systemu nie związanego z szablonami?

...

A gdyby zrobić tak: jest sobie kod HTML, w nim formularz, i jakiś parser zamienia to w php który wstawia odpowiednie wartości. Tzn:
[xml:1:b2681a3a0d]<form action="foo.php" method="post">
blah blah
<div id="bar-error" class="form-error"/>
<input type="text" name="bar" class="form-input"/>
</form>[/xml:1:b2681a3a0d]
zamieniamy na:
[php:1:b2681a3a0d]<form action="foo.php" method="post">
blah blah
<?php if ($jest_błąd_w_bar) { ?>
<div id="bar-error" class="form-error">
<?php echo $info_o_błędzie_w_bar; ?>
</div>
<?php } ?>
<input type="text" name="bar" class="form-input" value="<?php echo $zawartość_bar; ?>">
</form>[/php:1:b2681a3a0d]
Taką transformację można albo zrobić sobie offline, albo w jakiś magiczny sposób generować za każdym razem jak zmienia się plik oryginalny. A w php będzie sobie obiekt formularza, który robi walidację itd, i ustawia odpowiednie zmienne, żeby do HTML wstawiło się to co trzeba.
W końcu PHP5 ma parser DOM do HTMLa, więc parsowanie jest debilne: getElementsByTagName('form') itd. Walidacja itd to inna sprawa, ale coraz bardziej mi sie to podoba .

[Seth]

Tez nie jestem zachwycony tego typu klasami gdyz jak napisal hawk nie daja pola osobie tworzacej strone do swobody.

Juz raczej bym zrobil to w ten sposob, ze specjalne tagi - tak jak np w asp.net:
[xml:1:4bb69f8d0d]...
<asp:Label runat="server" ...>
...
[/xml:1:4bb69f8d0d]
... sa zamieniane na obiekty w skrypcie. Wtedy deisgner ma swobode w tworzeniu strony, a my mamy dostep do obiektow uzytych przez niego.

[hawk]

No czyli wypisz wymaluj WACT. Wada jest taka, że coś te taki musi parsować, czyli albo nakładamy na system szablonów kolejną warstwę, albo jest to integralna część tego systemu (WACT). A kolejna warstwa boli, bo to wymaga albo wielkich regexpów, albo DOMa, albo czegoś jeszcze bardziej zakręconego.

Dlatego IMHO taka dodatkowa warstwa musi parsować plik tylko raz, i wygenerować sobie kod php który potem wystarczy do połapania się gdzie jest formularz. Możesz w moim przykładzie zamienić <label .../> na <foobar:label .../>, to tylko kwestia jakie tagi łapie engine. Moja wersja ma tą zaletę, że oryginalny plik jest poprawnym HTML, co ułatwia pisanie w różnych narzędziach.

Ewentualnie można dodawać do tagów, które mają być przerabiane, jakąś specjalną klasę CSS albo coś w tym stylu.

A jeżeli ta wspaniała warstwa ma generować sobie reużywalny php i parsować ponownie tylko wtedy gdy plik źródłowy się zmienił, to dochodzimy to czegoś takiego jak pokazałem, wzbogaconego o inne kontrolki oczywiście - radio, checkboxy, etc.