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]

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

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

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.

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

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

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]

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

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.

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

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

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.

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ć?

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.

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

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

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 .

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.

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.

Czyli - jeśli dobrze rozumuję - chodzi o coś takiego:

1. Rejestrowanie pól formularza i definiowanie reguł ich walidacji, etc.

2. Parsowanie pliku ustawień wizualnych (tworzone przez designerów) formularza - style, klasy, czy może nawet typ używanych elementów - to w jakimś pliku konfiguracyjnym... czy to właśnie przyjmującym formę html, czy też jakiś inny xml...

3. Wysyłanie przygotowanych danych do szablonów w formie zmiennych (np: $forms.elements.nazwa_pola, etc.).


Oczywiście tak jak piszesz Hawk - pkt drugi kompilowany jedynie w przypadku zmian plików konfiguracyjnych.

Czy może jednak źle zrozumiałem wasze pomysły?

Generalnie jakoś nigdy nie byłem przekonany do tworzenia klas generujących formularze - właśnie z powodu mieszania prezentacji z kodem odpowiedzialnym za tworzenie formularzy... Ale... ...to mi się zaczyna podobać )

heh... faktycznie, to trzeba by wkręcić w jakiś system szablonów, np. SMARTY - jako dodatkowy moduł. Bo mieszanie warstw... przecież nie po to są szablony żeby obciążać warstwą prezentacyjną kodera PHPa... Myślę, że tutaj dobrego rozwiązania: brak.

Czemu od razu wkręcać na stałe? Nie lepiej zrobić na zasadzie adapterów - używać jednej abstrakcyjnej klasy... a każdy już sobie napisze odpowiedni adapter, który będzie korzystał z jego kochanego systemu template'ów )

Nie do końca. Ja chcę żeby nie było osobngo pliku z wyglądem formularza. Tylko żeby system formularzowy wyciągał wszystko co trzeba bezpośrednio z pliku, w którym jest cała reszta strony. Przezroczyste dla designera. A po stronie php prawdopodobnie dodatkowe ogniwo w procesie przetwarzania.

Tylko pytanie, jak i gdzie je wstawić. Posługując się przykładem Smarty... przed Smarty? po Smarty (output buffering, fetch zamiast display, itd)? plugin do Smarty?


No ja też nie. Generalnie to tu ścierają się - w uproszczeniu - 2 koncepcje architektury tego wszystkiego: oryginalna (scannera?) i moja. Jak dla mnie: nie generacja formularza, tylko transformacja statycznego formularza do czegoś bardziej inteligentnego. Tak jak chce halfik: bez mieszania warstw.

Heh, powinienem pisać manifesty filozoficzne

ja tylko wyszczegolnie watek ktory zaniknal w toku dyskusji. chodzi o klase ktora pozwala na dynamiczne generowanie formularzy za pomoca jej metod, sprawdzac poprawnosc wprowadzanych danych i umozliwiac dowolne ustawianie pol formularza wg uznania ( przynajmniej ja to tak widze) a za wyglad odpowiadalyby dolaczane znaczniki class=" ... " i plik css ktory jest w kazdym systemie stosowany.

Ten wątek wcale nie zaniknął. Byłoby to coś w stylu POF. Ale czy to jest słuszna droga? Bo były w wątku już przykłady kodu, a nie było info, dlaczego taka wizja systemu jest lepsza niż inna. Zaczynanie od końca.

Ale jest inny wątek który zupełnie się zapodział w dyskusji. Jak już jest klasa która waliduje co trzeba, to co dalej? Jest formularz, wypełniam, klikam submit, są błędy -> co się dzieje?

Uwaga, ja się lubię czepiać szczegółów . Bo to wcale takie proste nie jest. Zrobić redirecta? Wyświetlić ten sam formularz po raz drugi na nowej stronie (a skąd go wziąć?). Wyświetlić stary (poprzedni) szablon, na którym był ten formularz? A co jak formularz był generowany dynamicznie (taki wieloetapowy wizard)? Dla przykładu:
1) jest formularz, pytanie o liczbę dzieci, wpisuję 5 i submit
2) drugi formularz, 5 edit boxów na imiona, nie wpisuję i submit
3) walidator zauważa brak imion, jest błąd
4) wyświetlamy znowu formularz z imionami, ale ile ich było?

jedynym rozwiazaniem wg mnie w tym przypadku jak i samej konstrukcji walidatora jest uzycie sesji do zapamietywania danych ktore sa wpisane do formularza i jego samych wlasciwosci

Hmm, z drugiej strony ja zawsze myślałem że takie rzeczy jak reguły walidacyjne lepiej trzymać w jakimś pliku konfiguracyjnym (najlepiej XML kompilowany do serializowanego obiektu - ostatnio jestem fanem tego rozwiązania, jest szybsze niż czysty kod php - sprawdzałem), i niech sobie jakiś FormController z niego wyciąga co trzeba.

Z trzeciej strony, taka konfiguracja raczej na sztywno by określała co do jakich pól, a tutaj mamy nie wiadomo ile pól... Sesja tutaj faktycznie jest dobra, bo można zostawić wskazówkę walidatorowi, żeby sprawdził 5 pól. Tu bym chętnie zobaczył jakiś zgrubny przykład albo projekt, to nawet ciekawsze i ważniejsze niż $form->addInput('blah') itd.