Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: ad.2. Formularze
Forum PHP.pl > Forum > PHP > Pro > Archiwum Pro
dragossani
Temat chciałem rozpocząć od problemu nawigacji. Nie wiem na ile złożone formularze musieliście tworzyć, ale pozwolę sobie użyć przykładu z jakim ja się stykam na codzień.
Mamy stworzyć aplikację, która pozwala zawrzeć przez internet umowę ubezpieczenia. Musimy spytać o przystępujące do umowy strony (ubezpieczający, ubezpieczony, ubezpieczyciel, uposażony, cesjonariusze itd.), każda ze stron może być osobą lub podmiotem, może być właścicielem ubezpieczanego mienia, współwłaścicielem, użytkownikiem itd. Firmy mają czasem po kilka adresów i telefonów. Potem mamy przedmiot ubezpieczenia - jeden bądź więcej. Warunki ogólne (okres, sumy, limity, dotychczasowe umowy itd.). Pewne elementy wynikają z siebie, inne nie. Generalnie saigon znczy się przejebane jak w ruskim czołgu.
No i teraz mamy napisać do tego nawigację, taką, żeby można sobie swobodnie dodawać odpowiednie elementy, nieraz wielokrotnie, musi działać kontrola danych oraz możliwość cofnięcia się i poprawienia dowolnego elementu, a potem powrót do normalnego trybu wypełniania.

8O ... rolleyes.gif

Jak ktoś ma gotowe rozwiąznie to niech mi przyśle biggrin.gif

Na razie wykombinowałem kilka ważnych elementów. Mianowicie: nawigacja musi działać w pętli. Przecież nie zawsze przeładowywujemy stronę przed wyświetleniem nowego formularza. Po wypełnieniu post'ujemy zmienne do siebie (dlaczego, chyba nie muszę tłumaczyć) i sprawdzamy poprawność. Jeśli są błędy to wyświetlamy ten sam formularz ale informujemy o błędach, a jeśli wszystko ok? No to musimy wyświetlić kolejny formularz ale strony nie przeładowujemy - dlatego przydaje się pętla. Moduł nawigacji może wyglądać np. tak (nazwijmy go powiedzmy "nawigacja.php"):
Kod
<?php

session_start();



if (empty($_POST['form_name']))

{

    $_SESSION['dane']=$_SESSION['nawigacja']=array();

    $_SESSION['nawigacja'][]='strona_2';

    $_SESSION['nawigacja'][]='strona_1';

    $form_name=array_pop($_SESSION['nawigacja']);

};



//nadpisujemy 'form_name' i 'post_name' jeśli przyszły post'em

if (!empty($_POST['form_name'])) $form_name=$_POST['form_name'];

if (!empty($_POST['post_name'])) $post_name=$_POST['post_name'];



//definiujemy cechy pliku

$file_root='';

$file_extension='.inc';



while ($form_name)

{

    //przenosimy nazwę formularza na inną zmienną

    $temp_form_name=$form_name;

    

    //blokujemy pętle

    $form_name='';



    //kontrolujemy czy to pierwsze wyświetlenie formularza

    $first_time=((!($temp_form_name==$post_name))||$once_again);



    //czyścimy zmienne

    $errors=$values=array();

    $once_again=false;



    //definiujemy plik formularza

    $file=$file_root.$temp_form_name.$file_extension;



    //ładujemy odpowiedni formularz

    include($file);

}



function cut_blank($value) {return (trim($value)=='') ? false : true;}



function set_values(&$values)

{

    //tworzymy tablice wartości pól

    //jeśli ktoś ma ponazywane przyciski

    //submit to tutaj można wyciąć

    //ich wartość z tablicy

    $values=$_POST;

    unset($values['form_name']);

    unset($values['post_name']);

    unset($values['post_once_again']);

}



function set_variable($name,$value)

{

print("<INPUT TYPE="HIDDEN" NAME="$name" VALUE="$value">n");

}

?>

W kodzie tym jest jeszcze jeden ciekawy element - zmienna $_SESSION['nawigacja']. Jest to stos sterujący przebiegiem wypełniania formularzy. Na początku wypełniamy go listą kolejnych formularzy i zdejmujemy ze stosu pierwszy element. Zostaje on uruchomiony w pętli. Każdy kolejny formularz wykonuje się i zdejmuje ze stosu następny element (czyli wskazuje kto ma być po nim). No chyba, że ktoś źle wypełnił formularz. Wówczas nie wskazujemy następcy lecz wykonujemy formularz jeszcze raz i pozwalamy userowi dokonać poprawek. Możliwa jest też sytuacja, że chcemy ponownie wyświetlić formularz, pomimo że ten wypełniono poprawnie. Nie ma problemu. Formularz dodaje siebie samego na stos i po kłopocie.
Pliki następnych dwóch formularzy (mamy je na stosie zgodnie z pierwszym skryptem) mogą wyglądać tak:
plik "strona1.inc":
Kod
<?php

//sprawdzamy czy to pierwsze wyświetlenie formularza

if ($first_time)

{

    //jeśli to pierwsze wyświetlenie

    //to tu możesz wykonać czynności wstępne

    //np. ustawić domyślne wartości pól formularza

} else {

    //to nie pierwsze wyświetlenie (wypełniono formularz)



    //pobieramy zmienne które przyszły post-em

    set_values($values);

    

    //tu możemy dokonać kontroli poprawności

    if(empty($_POST['imię'])) $errors['imię']='Proszę podać imię.';

    if(empty($_POST['nazwisko'])) $errors['nazwisko']='Proszę podać nazwisko.';

};



//jeśli już wypełniono formularz i sprawdziliśmy

//że nie ma w nim błędów to zapisujemy dane w sesji

if ((!$first_time)&&(empty($errors))) {

    

    //jeśli formularz ma nam posłużyć jeszcze raz

    //to każemy mu się wyświetlić ponownie

    if ($_POST['post_once_again']=="true")

    {

  $_SESSION['nawigacja'][]=$temp_form_name;

  $once_again=true;

    };



    //dopisujemy komplet danych do sesji

    //array_filter usuwa puste elementy tablicy

    $_SESSION['dane'][]=array_filter($values,"cut_blank");

    

    //bierzemy w obroty następny formularz

    $form_name=array_pop($_SESSION['nawigacja']);

} else {

//wyświetlenie formularza

?>

<HTML><BODY>

<FORM NAME="Form1" ACTION="<?= $_SERVER['PHP_SELF'] ?>" METHOD="POST" ACCEPT-CHARSET="iso-8859-2">

<?php

//ustawianie zmiennych które trzeba wysłać

set_variable('form_name',$temp_form_name);

set_variable('post_name',$temp_form_name);

set_variable('post_once_again','false');

?>

<TABLE ALIGN="CENTER" CELLSPACING="0" CELLPADDING="0" BORDER="1" STYLE="width: 400px">

<TR><TH>Formularz 1</TH></TR><TR><TD>



    <TABLE CELLSPACING="1" WIDTH="100%">

  <TR>

     <TD STYLE="width: 100px">

    Imię:

     </TD>

     <TD>

    <INPUT TYPE="TEXT" NAME="imię" STYLE="width: 200px" VALUE="<?= $values['imię'] ?>">

    <?php if(!empty($errors['imię'])) print("<BR>".$errors['imię']); ?>

     </TD>

  </TR>

  <TR>

  <TR>

     <TD STYLE="width: 100px">

    Nazwisko:

     </TD>

     <TD>

    <INPUT TYPE="TEXT" NAME="nazwisko" STYLE="width: 200px" VALUE="<?= $values['nazwisko'] ?>">

    <?php if(!empty($errors['nazwisko'])) print("<BR>".$errors['nazwisko']); ?>

     </TD>

  </TR>

  <TR>

  <TR>

     <TD STYLE="width: 100px">

    Pole opcjonalne:

     </TD>

     <TD>

    <INPUT TYPE="TEXT" NAME="opcjonalne" STYLE="width: 200px" VALUE="<?= $values['opcjonalne'] ?>">

     </TD>

  </TR>

  <TR>

    </TABLE>

    

</TD></TR><TR><TD><BR><UL>

     <LI><A HREF="javaScript: document.Form1.submit();">Zapisz dane i przejdź dalej.</A>

     <LI><A HREF="javaScript: document.Form1.post_once_again.value='true'; document.Form1.submit();">Zapisz dane i pozwól mi dodać kolejną osobę.</A>

     </UL>

  </TD>

    </TR>

</TABLE><BR>

<?php

};

?>

Plik "strona2.inc":
Kod
<?php

    print('<PRE>');

    print_r($_SESSION['dane']);

    print('</PRE>');

    session_destroy();

?>

Dane gromadzone są w tablicy $_SESSION['dane']. Podsumowanie wyświetlamy sobie na "strona2.inc". Stwórzcie sobie te 3 pliki i odpalcie, powinny działać. Kod nie jest piękny (o tym za chwilę) ale spełnia swoją funkcję.

To jednak dopiero pierwszy krok. Dalej wizja jest taka: trzeba stworzyć drugi stos, na który odkładalibyśmy to, co już zostało poprawnie wypełnione. Dzięki temu w każdym momencie mielibyśmy pełny raport o tym gdzie jesteśmy, co już za nami, a co przed nami. Wyrzucamy sobie tą informację u góry okna (albo z boku - coś jak w setupie od Mandrake'a) i pozwalamy userowi łazić po formularzach w te i we fte ;-)

W międzyczasie zauważamy kolejną trudność. W przypadku błędu musimy wyświetlić formularz ponownie, ale dane które już są wypełnione, muszą takimi pozostać. Trzeba mieć więc możliwość nadania elementom formularza wartości domyślnych. Kiedy posługujemy się tylko polami tekstowymi w formularzu, to nie ma problemu - działa to jak w powyższym przykładzie. Ale co wtedy, gdy mamy pola typu checkbox, radio, select, multi-select czy też daty albo jeszcze czegoś dziwniejszego? Musimy stworzyć sobie bibliotekę komponentów które będzie można odpalić jednym poleceniem i nadać im przy tym wartość. Ja taką bibliotekę mam już częściowo napisaną, mogę ją opublikować. Niestety tworzyłem ją wtedy, gdy o obiektach w php wiedziałem jeszcze niewiele. Zadanie jest więc spore - trzeba przełożyć wszystkie komponenty formularza na system klas, a sam formularz przerobić na wersję obiektową.
Jest jeszcze problem rozgałęzień. Czasami trzeba w konkretnym formularzu zejść ze ścieżki wytyczonej przez stos, dodać na wierzch kilka pośrednich elementów (np. formularze do dodawania adresów i telefonów do osóB), wypełnić je, a potem kierująć się stosem wrócić do normalnego biegu wydarzeń. Da się to oczywiście zrobić, ale jeśli miałoby to działać na obiektach to musiałoby być bardzo spójnie napisane.
Kontrola poprawności pól powinna być w budowana w klasę danego komponentu formularza, tak by odpowiednia metoda sprawdzała poprawność danych.
Co sądzicie o takiej formie magazynowania danych jak użyta powyżej tablica 'dane'? Może lepszy byłby XML? Za chwilę trzeba będzie przecież wrzucić wyniki formularza do bazy danych i problem zyska na wadze. Poza tym czasami musimy wypełnić formularz domyślnymi danymi z bazy. Przykład: ktoś wklepuje pesel, powinien wklepać resztę danych osoby, ale okazuje się, że nie musi - mamy tą osobę już w bazie. Trzeba mu znalezione dane wyświetlić i pozwolić skorygować. I tu wychodzi na wierzch problem uspójnienia operacji wejścia/wyjścia, tzn. ujednolicenia formatu źródeł danych (formularz, baza, informacje z zewnątrz) i wyjścia danych (strona html - raport, formularz html - dane do skorygowania, plik pdf, zapis do bazy, wysyłka na inny serwer itd.). XML przypomina o sobie z nową siłą.
I jeszcze drobnostka: ma ktoś pomysł na wysłanie odpowiednich zmiennych w zależności od tego co user kliknie na dole formularza? W powyższym skrypcie robi to JavaScript ale metoda jakoś mi się nie podoba. Ma ktoś inny pomysł?

Formularze to chyba temat dla każdego aktualny. Mam więc nadzieję, że niektórych sprawa zainteresuje. Ciekawe linki na ten temat są przy podpunkcie na liście proponowanych przeze mnie tematów.
dragossani
Aha, jeszcze jedna sprawa. Kod komponentów powinien być oddzielony od wyglądu. Kłaniają się szablony PHPLib'a. Np. biblioteka PhpObjectFormsLibrary (link na liście tematów) jest interesującym rozwiązaniem jeśli chodzi o obiektowość formularza. Nie oddziela niestety kodu od wyglądu (duży minus) i z tego co wiem nie posługuje się stosem (duże utrudnienie). Możnaby się zabrać za jej przerabianie smile.gif
hyper
Zastanawia mnie jedna rzecz. Często wymieniasz nazwy różnych
systemów szablonowych, ale ani razu nie zauważyłem wzmianki o
Smarty (http://smarty.php.net/). Myśle, że warto się nim
zainteresować, jeśli jeszcze się z nimi nie spotkałeś.

Ogólne porównanie jest takie, że Smarty są bardziej rozbudowane,
kosztem wolniejszego działania od FastTemplate.
weezy
fajne te twoje arty ale lepiej by one sie przydaly na php.pl w dziale artykuly niz tutaj... przynajmniej ja i kilku moich znajomych tak uwaza
dragossani
Ja też bym tak uważał gdyby to miałyby być artykuły. Nie chodziło jednak o monolog. Założenie było takie, żeby to był przyczynek do dyskusji, a nie artykuł do przeczytania i przyjęcia do wiadomości. Niestety jakoś nikt się nie kwapi do pisania.
W tym tekscie powyżej jest wiele niewiadomych. Nikt ich jednak nie komentuje ani nie wytyka. Nikt nie przyznaje się, że ma to zrobione u siebie inaczej, lepiej... Na to nie mam wpływu.

Chciałem jeszcze dopisać nieco do tematu sesji - w zakresie przekazywania identyfikatorów. Testuję właśnie u siebie pewne rozwiązania. Obawiam się właśnie tylko tego, że napiszę o tym i będzie to ostatni post w tym wątku. To od was zależy czy php.pro będze FORUM wymiany opinii czy tylko tablicą ogłoszeń...
weezy
no wiec wlasnie potestuj sesje u siebie i uzupelnij ten artykul i daj go na php.pl i wszyscho bedzie okej smile.gif
dragossani
Cytat
nie zauważyłem wzmianki o
Smarty (http://smarty.php.net/). Myśle, że warto się nim
zainteresować

Przedzieram się właśnie przez dokumentację i jestem coraz bardziej zaciekawiony smile.gif Nie znałem tego projektu. Masz jakieś doświadczenia związane z użytkowaniem tego modułu? Gdybyś napisał parę słów w nowym wątku to możnaby rozwinąć temat.
castor
witam,

podchodzisz do sprawy dobrze, przechowywanie danych w sesji do dobry pomysl.
ten skrypcik jest jednak trosze bez potrzeby zakrecony, to jest prosty formularz ..mozna by bylo prosciej i z takim samym efektem.

Nie wiem na jakim php to testowales i jaki poziom reportowania bledow miales. Jest w skrypcie jeden blad. tzn.
Przy pierwszym odpaleni zmiena post_name nie jest zdefiniowana! Nie przeszkadza to w poprawnej pracy skryptu lecz jest to bleden. I zmienna once_again po probie dodania kolejnej osoby tez nie jest zdefiniowana.


Ten stos nawigacyjny tez jest dobrym pomyslem w praktyce pracuje podobnie.


Kod
   //kontrolujemy czy to pierwsze wyświetlenie formularza

   $first_time=((!($temp_form_name==$post_name))||$once_again);

dlaczego tak?
przeciez masz juz zmienna once_again ktora ma wartosc true lub false.


Sprawdzenie czy pierszy raz zostaje wywolany formularz mozna bylo by zrobic troszke w inny sposob.Np zmienna w sesji ktora ma wartosc 0 na poczatku i w zaleznosci od poziomu na ktory sie znajdujemy taka wartosc przyjmuje.

Twoj sposob nie jest zly lecz zakrecony :wink:

Cytat
Mianowicie: nawigacja musi działać w pętli. Przecież nie zawsze przeładowywujemy stronę przed wyświetleniem nowego formularza. Po wypełnieniu post'ujemy zmienne do siebie (dlaczego, chyba nie muszę tłumaczyć) i sprawdzamy poprawność. Jeśli są błędy to wyświetlamy ten sam formularz ale informujemy o błędach, a jeśli wszystko ok? No to musimy wyświetlić kolejny formularz ale strony nie przeładowujemy - dlatego przydaje się pętla.


przeczytaj to jeszcze raz i zastanow sie nad tym co napisales :wink:


Kod
<INPUT TYPE="TEXT" NAME="imię" STYLE="width: 200px" VALUE="<?= $values['imię'] ?>">

to przy pierwszym wyswietleni formularza nie bedzie zmiennej $values['imie'] i wzaleznosci od raportowania bledow pojawia sie w TextFieldzie komunikaty z bledem:
Kod
<?=(isset($values['imie']))?$values['imie']:''; ?>



podsumowujac idziesz w b dobrym kierunku! przelozenie formularza na werscje objektowa jest b,dobrym pomyslem ulatwi ci to prace przy skomplikowanych formularzach




Cytat
I jeszcze drobnostka: ma ktoś pomysł na wysłanie odpowiednich zmiennych w zależności od tego co user kliknie na dole formularza? W powyższym skrypcie robi to JavaScript ale metoda jakoś mi się nie podoba. Ma ktoś inny pomysł?


raczej nie ma...
moze...drugi formularz z hiddenFieldami :wink: ....lecz twoja metoda jest ladniejsza
dragossani
[quote="Castor"]ten skrypcik jest jednak trosze bez potrzeby zakrecony, to jest prosty formularz ..mozna by bylo prosciej i z takim samym efektem[/qoute]
Naturalnie, że TEN formularz można zrobić prościej. To tylko przykład. Mechanizm jest pomysłem rozwiązania formularzy bardziej złożonych. Przede wszystkim rozgałęzionych.

[quote]Nie wiem na jakim php to testowales i jaki poziom reportowania bledow miales. Jest w skrypcie jeden blad.[/quote]
Święta racja. smile.gif Dzięki za czujność.

[quote]Ten stos nawigacyjny tez jest dobrym pomyslem w praktyce pracuje podobnie.[/quote]
Cieszę się, że się podoba. Testuję właśnie wersję podwójną o której pisałem.

[quote]dlaczego tak? przeciez masz juz zmienna once_again ktora ma wartosc true lub false.[/quote]
Chcemy określić czy to pierwsze wywołanie formularza. Od zmiennej $first_time zależy czy jest przeprowadzana potem kontrola błędów itp. Pierwszy raz dotyczy 2 sytuacji: gdy weszliśmy na bierzący formularz z innego i widzimy go po raz pierwszy (część warunku przed || ), oraz sytuacji gdy formularz bierzący został wypełniony poprawnie, ale chcemy go użyć ponownie (część po ||).

[quote]Sprawdzenie czy pierszy raz zostaje wywolany formularz mozna bylo by zrobic troszke w inny sposob.Np zmienna w sesji ktora ma wartosc 0 na poczatku i w zaleznosci od poziomu na ktory sie znajdujemy taka wartosc przyjmuje.[/quote]
Chodzi tylko o umieszczenie $first_time w sesji, czy miałeś coś więcej na myśli? Możesz napisać nieco dokładniej i jakie są tego zalety? smile.gif

[quote]Twoj sposob nie jest zly lecz zakrecony[/quote]
Chętnie poczytam o prostszym. biggrin.gif To wstępna wersja pomysłu. Właśnie z wymiany doświadczeń byłbym najbardziej zadowolony.

[quote]przeczytaj to jeszcze raz i zastanow sie nad tym co napisales[/quote]
Hmm... Coś sknociłem w wywodzie? smile.gif "nie zawsze przeładowywujemy stronę przed wyświetleniem nowego formularza" - o to chodzi? Przeładowujemy oczywiście. Tyle że plik załączany include'm, którego używamy jest ten sam co przed przeładowaniem. Dopiero jak go "wyciśniemy" to musimy się zabrać za następny - bez przeładowania. Jeśli coś jeszcze się nie zgadza w tej wypowiedzi to sprecyzuj, oki? smile.gif

[quote]wzaleznosci od raportowania bledow pojawia sie w TextFieldzie komunikaty z bledem[/quote]
Racja. U mnie jest raportowanie zbyt liberalne, dlatego nie ma problemu.

Piszesz, że sposobu na ominięcie JavaScript'u nie ma... Trochę szkoda. Jak wiadomo JS jest jakby trochę niepewnym narzędziem. Tu polecenie jest na szczęście proste - na Mozilli (javascript debugger) się nie wali, więc jest szansa, że działa prawie wszędzie.

Thnx za komentarz, jeśli masz jakiś ciekawy kod w tym temacie to publikuj. smile.gif
castor
Cytat
Chcemy określić czy to pierwsze wywołanie formularza. Od zmiennej $first_time zależy czy jest przeprowadzana potem kontrola błędów itp. Pierwszy raz dotyczy 2 sytuacji: gdy weszliśmy na bierzący formularz z innego i widzimy go po raz pierwszy (część warunku przed || ), oraz sytuacji gdy formularz bierzący został wypełniony poprawnie, ale chcemy go użyć ponownie (część po ||).

Ok! w takiej sytuacji to moze miec sens ...

Cytat
Chodzi tylko o umieszczenie $first_time w sesji, czy miałeś coś więcej na myśli? Możesz napisać nieco dokładniej i jakie są tego zalety? smile.gif

wiecej..
..umieszczenie zmiennej np: $poziom kazdy formularz wysyla ukryta zmiena pokazujaca glebokosc poziomu np:
1,2,3,4,5 itd. i wzaleznosci od tego gdzie sie znajdujemy nasza zmienna przyjmuje wartosc danego poziomu.

Do tego mozemy w tablicy $poziomy zapisywac na ktorych poziomach juz user byl i powracajac na jakis poziom automatycznie wiemy czy jest tu pierwszy raz czy juz tu byl i czy przyszedl tu droga ustalona przez poprzedzajace poziomy czy wskoczyl gdzies po drodze.

Cytat
Chętnie poczytam o prostszym. biggrin.gif To wstępna wersja pomysłu. Właśnie z wymiany doświadczeń byłbym najbardziej zadowolony.

mi chodziklo ze do tego formularza bylo to troche niepotrzebnie skomplikowane. Sama logika jesli uzyc jej w skomplikowanych formularzach powwina sie sprawdzic.

Cytat
Hmm... Coś sknociłem w wywodzie? smile.gif "nie zawsze przeładowywujemy stronę przed wyświetleniem nowego formularza" - o to chodzi? Przeładowujemy oczywiście. Tyle że plik załączany include'm, którego używamy jest ten sam co przed przeładowaniem. Dopiero jak go "wyciśniemy" to musimy się zabrać za następny - bez przeładowania. Jeśli coś jeszcze się nie zgadza w tej wypowiedzi to sprecyzuj, oki? smile.gif


tak i o to:
"
... No to musimy wyświetlić kolejny formularz ale strony nie przeładowujemy"

jak ty chcesz wyswitlic w php kolejny formularz bez przeladowania strony? :wink:

Cytat
Piszesz, że sposobu na ominięcie JavaScript'u nie ma... Trochę szkoda.

Jak wiadomo JS jest jakby trochę niepewnym narzędziem. Tu polecenie jest na szczęście proste - na Mozilli (javascript debugger) się nie wali, więc jest szansa, że działa prawie wszędzie.


tak prosta JS bedzie wszedzie dzialac gdy user ma ja wlaczona smile.gif
Cytat
Thnx za komentarz, jeśli masz jakiś ciekawy kod w tym temacie to publikuj. smile.gif


nie mam ...formularze pisze pod dane aplikacje i sa one do nich dopasowane wiec ciezko tu o uniwersalna recepte :wink:
dragossani
Cytat
..umieszczenie zmiennej np: $poziom kazdy formularz wysyla ukryta zmiena pokazujaca glebokosc poziomu np: 1,2,3,4,5 itd. i wzaleznosci od tego gdzie sie znajdujemy nasza zmienna przyjmuje wartosc danego poziomu.
Generalnie formularz ma tylko 2 stany w kórych może się znajdywać. Pierwsze wyświetlenie albo kontrola danych+zapis. Tu chyba levele są niepotrzebne. Jeśli chodzi o rozgałęzienia formularzy, a tym samym zchodzenie na niższe poziomy, to od strony nawigacyjnej rozwiązuje sprawę stos. Rozgałęzienie - dokładamy na stos odpowiednią ścieżkę. Rozgałęzienie w rozgałęzieniu? Dokładamy znów. Formularze zchodzą na kolejne poziomy, a po wykonaniu wchodzą spowrotem. Pomysł jest jednak przydatny z innego punktu widzenia. Może być przydatny przy wyświetlaniu linków do nawigacji w sposób hierarchiczny oraz do tworzenia zapisu danych w formie drzewkowej. Tu jest pole do popisu.

Cytat
jak ty chcesz wyswitlic w php kolejny formularz bez przeladowania strony?
Źle się wyraziłem. Zamiast "wyświetlić" powinno być "przetworzyć". Sorry :oops:

Cytat
...formularze pisze pod dane aplikacje i sa one do nich dopasowane wiec ciezko tu o uniwersalna recepte
Jednak są pewne zagadnienia przy formularzach, które się powtarzają. Kontrolę danych i nawigację możemy wykorzystywać w wersjach prostych jak i skomplikowanych. Nawet w najprostszych formularzach kontrola wprowadzanych danych się przydaje. Mi chodzi poza tym po głowie metoda na błyskawiczne budowanie formularzy. Jeśli mielibyśmy klasy do obiektwego tworzenia formularza, oddzielony kod od wyglądu i jakieś narzędzie do posługiwania się tym bez potrzeby pisania kodu (jakiś front-end) to praca przy tworzeniu formularzy ograniczałaby się do wprowadzenia listy pól formularza (z ustaleniem kontroli poprawności danych) oraz dostosowania wyglądu do potrzeb projektu (ale to już nie my tylko grafik). W ogóle możnaby wtedy trzymać formularze w bazie (lista pól + kontrola poprawności) i już.
castor
Cytat
Generalnie formularz ma tylko 2 stany w kórych może się znajdywać. Pierwsze wyświetlenie albo kontrola danych+zapis. Tu chyba levele są niepotrzebne. Jeśli chodzi o rozgałęzienia formularzy, a tym samym zchodzenie na niższe poziomy, to od strony nawigacyjnej rozwiązuje sprawę stos. Rozgałęzienie - dokładamy na stos odpowiednią ścieżkę. Rozgałęzienie w rozgałęzieniu? Dokładamy znów. Formularze zchodzą na kolejne poziomy, a po wykonaniu wchodzą spowrotem. Pomysł jest jednak przydatny z innego punktu widzenia. Może być przydatny przy wyświetlaniu linków do nawigacji w sposób hierarchiczny oraz do tworzenia zapisu danych w formie drzewkowej. Tu jest pole do popisu.

Tak.. tylko ze ja mialem na mysli cos innego:
Pobierajac jakies tam dane od Usera nie pobieram ich na raz w jednym duzym formularzu tylko na pare razy dziele je na jakies tam kategorie.
cala procedura zarejstrowania sie i zakupienia polisy ma np 5 poziomow. Jesli ktos jest juz zarejstrowany to ma ona tylko 2 czy trzy poziomy. i chodzi mi o sledzenie gdzie sie znajduje i gdzie juz byl lub co juz zamowil ..chociazby ze wzgledu wyswietlenia mu odpowiedniego banera.
Ma to swoje plusy rowniez przy zmianach danych bo jesli jedne dane sa zalezne od drugich to mozesz poinformowac go o konsekwencjach i potrzeby zmiany innych danych po dokonaniu operacji przez niego. bo wiesz gdzie juz byl.

dobrym przykladem tego moga byc kofiguratory wyposazenia aut.

Stosy sa dobre tylko przy rozgalezieniach jakie sa np: w sklepach internetowych nie jestes w stanie przedstawic drogi USERA jaka on przebyl na serwisie trafiajac tu.

Ja tak pracuje(owalem) :wink:

Cytat
Jednak są pewne zagadnienia przy formularzach, które się powtarzają. Kontrolę danych i nawigację możemy wykorzystywać w wersjach prostych jak i skomplikowanych. Nawet w najprostszych formularzach kontrola wprowadzanych danych się przydaje. Mi chodzi poza tym po głowie metoda na błyskawiczne budowanie formularzy. Jeśli mielibyśmy klasy do obiektwego tworzenia formularza, oddzielony kod od wyglądu i jakieś narzędzie do posługiwania się tym bez potrzeby pisania kodu (jakiś front-end) to praca przy tworzeniu formularzy ograniczałaby się do wprowadzenia listy pól formularza (z ustaleniem kontroli poprawności danych) oraz dostosowania wyglądu do potrzeb projektu (ale to już nie my tylko grafik). W ogóle możnaby wtedy trzymać formularze w bazie (lista pól + kontrola poprawności) i już.

to co napisales odbieram jak cos w rodzaju generatora formularzow...
..dobry pomysl...do malych aplikacji.

.....lecz nadal twierdze ze przy duzych skomplikowanych aplikacjach caly naped ,nawigacja czy kontrola danych jest bardzo zalezna od budowy aplikacji.
dragossani
Sprawę takich poziomów o których piszesz podwójny stos chyba rozwiązuje. Masz na jednym stosie uchwyty formularzy, które użytkownik musi jeszcze wypełnić, masz na drugim uchwyty tych, które już wypełnił - wystarczy przejrzeć stosy. Ponadto IMHO nie jest tak, że ilość formularzy zmniejsza się, jeśli np. mamy już jakąś osobę w bazie. I tak trzeba ją wyświetlić i pozwolić userowi skontrolować poprawność danych - musi mieć możliwość modyfikacji np. adresu. (a pamiętajmy, że poprzedni adres musi w bazie pozostać, bo mógł być z czymś powiązany).

Ciekawym zagadnieniem jest format przechowywania danych przychodzących POST'em z formularzy. Dobrym posunięciem byłoby sądze zmienienie zasady działania skryptu z "formularzocentrycznej" na "danocentryczną". O co chodzi? Przyjmijmy, że mamy 5 formularzy przez które user musi przejść. Pod każdym prezentowanym userowi formularzem wyświetlamy mu zestawienie tego, co już wypełnił. Na czwartym przypomniał sobie, że zrobił błąd w pewnym polu drugiego formularza. Zagląda więc na dół ekranu i klika [popraw] przy polu które źle wypełnił. Strona przeładowuje się, widać 1 pole (bądź więcej jeśli jego wartość jest powiązana z innymi, które należy też poprawić). User poprawia, a formularz kierująć się stosem wraca tam, skąd wyskoczył - czyli do formularza czwartego.
Co jest potrzebne by to było możliwe? Jakiś sposób na przechowanie danych w sposób identyfikujący każdy element. Jeśli trzymamy wszystko w tablicach - tak jak przyszło POST'em, a mamy do czynienia z rozgałęzieniami w formularzu, wielokrotnym używaniem tego samego formularza do wprowadzania np. kolejnych osób, to utrzymanie struktury danych w której możemy identyfikować precyzyjnie każde pole nie jest łatwe. I tu powraca pomysł obiektowej konstrukcji formularzy. Każdy element formularza (nawet jeśli był tworzony w oparciu o tą samą klasę) jest obiektem, jest unikatowy i istnieje samodzielnie. Najpierw go tworzymy, nadajemy mu wartość domyślną, nadajemy mu nazwę, określamy sposób kontroli poprawności, przypisujemy do jakiegoś formularza, definiujemy zależności między nim, a innymi obiektami. Potem każemy mu się wyświetlić. Następnie "wyręczamy" mu dane które wprowadził użytkownik i pytamy czy odpowiadają regułom poprawności. Jeśli wszystko jest ok, to przypisujemy mu odpowiednią wartość. Taki obiekt (np. pole tekstowe) może mieć metody: WyświetlJakoElementFormularza() - która wyświetla pole tekstowe i nadaje mu wartość domyślną; oraz WyświetlJakoOpis() - która tylko pokazuje tylko etykietę obiektu i jego wartość (np. Imię: Janusz). Tą drugą metodę wykorzystujemy do wyświetlania zestawień tego co user już wprowadził. Nad takim mechanizmem trwają już na świecie prace np. phpObjectForms Library do której link znajduje się przy propozycji tematów na to forum. Nie ma tam co prawda tak rozbudowanej nawigacji jak ta o której piszę, ale koncepcja jest zbliżona.
Idealnie byłoby, gdyby każdy obiekt miał też zdefiniowane miejsce w bazie danych w które mają trafić informacje w nim zawarte. Czyli obiekt przechowujący np. nazwisko trzeciej osoby dodawanej do umowy ubezpieczenia sam "wie", że gdy wywołamy na nim metodę ZapiszSwojeDaneDoBazy() to musi je umieścić np. w tabeli "osoby" w polu "nazwisko". Ten ostatni mechanizm to może nieco przegięty pomysł, ale gdyby udało się zdefiniować jakąś abstrakcyjną warstwę pośredniczącą między bazą danych, obiektami formularzy to byłoby coś.
Generalnie można spróbować każemu elementowi formularza pozwolić "żyć" autonomicznie i samodzielnie dbać o wszystko. Sesja zapewniałaby ciągłość.

Jeśli chodzi o to, żeby zrobić "generator formularzy" to zacząłbym od napisania odpowiednich bibliotek i udostępnienia wygodniego API. Jeśli byłoby to napisane odpowiednio elastycznie (uchwyty do realizacji samodzielnie jakiś metod, tam gdzie programista może mieć specyficzne potrzeby - tak jak w sesjach w php) to powinno to zadowolić większość piszących w php. Rozbudowane projekty mają specyficzne potrzeby, ale nie w każdym miejscu. Ktoś potrzebuje funkcjonalności której w tej bibliotece brakuje? Tworzy własny uchwyt do np. kontroli poprawności danych, taki który sprawdza je w oparciu o fazę księżyca na filipinach i podłącza do istniejących bibliotek, nadpisując domyślną metodę. Wszystko jest do zrobienia. By powstała taka biblioteka - roboty mnóstwo; ale przecież wszyscy to lubimy, prawda? winksmiley.jpg
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.