Formularze#

Ogólne ramy formularza#

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
<form action="...">
	...
</form>

Główne ramy formularza tworzone są przez znaczniki <form>...<form/> z odpowiednimi atrybutami. Między znacznikami umieszczamy właściwe elementy formularzy.

Formularzy nie można zagnieżdżać, tzn. umieszczać jednego w drugim. W przypadku korzystania z Strict DTD, wewnątrz znaczników <form>...<form/> muszą się znaleźć dodatkowe znaczniki obejmujące wszystkie elementy formularza. Znacznikami obejmującymi mogą być: div, p, fieldset, h1, h2, h3, h4, h5, h6, pre, address, ins, del. Jest to konieczne do zwalidowania kodu strony m.in. przez sieciowy walidator World Wide Web Consortium.

Pola formularzy (kontrolki) omówione zostaną na kolejnych stronach. Na chwilę obecną należy wyjaśnić znaczenie specyficznych atrybutów dla elementu form.

Adres docelowy (action)#

Atrybut action="..." określa adres strony, która ma odebrać dane (po wysłaniu formularza przez użytkownika). Pusta wartość oznacza tę samą stronę.

Atrybut action jest obowiązkowy, pominięcie go w znaczniku <form> jest błędem!

W najprostszym wypadku można wysłać dane pod wskazany adres e-mail (action="mailto:adres e-mail"). Częściej jednak podaje się adres strony, na której umieszczony został odpowiedni skrypt (ASP, PHP, CGI itp.). Skrypt taki jest specjalnym programem, uruchamianym i wykonywanym na serwerze WWW. Możliwości języków skryptowych po stronie serwera są ogromne. Można np. przetworzyć wszystkie dane i zapisać je do bazy danych czy plików. Dzięki temu oszczędzamy czas, a wyniki mogą być natychmiastowo wyświetlane na ekranie. Swobodne operowanie językami skryptowymi jest dużo bardziej skomplikowane niż tworzenie strony przy użyciu języków znacznikowych (xHTML, CSS). Są one kolejnym etapem nauki przy projektowaniu witryn internetowych.

Nie da się wysłać formularza do dwóch stron naraz ani wysłać pod różne adresy, zależnie od jego zawartości. Taką funkcjonalność można uzyskać, wysyłając formularz do skryptu, który przeanalizuje jego dane i sam wykona odpowiednie czynności (wczytanie innej strony, przekierowanie).

Metoda (method)#

W formularzu komunikującym się z językami po stronie serwera, za pomocą atrybutu method="..." należy dodatkowo określić typ żądania HTTP (GET, POST, HEAD itd.). Obecnie najpopularniejsze są dwie metody:

GET
Tej metody używa się ogólnie przy wysyłaniu małej ilości informacji na serwer np. przy wyszukiwarkach, wyborze wersji pliku itp. Dane formularza zostaną dołączone na końcu adresu strony docelowej w postaci klucz-wartość (jako Query String w URI, np. www.example.pl/test.php?&nazwa1=wartosc1&nazwa2=wartosc2) i następnie pobrane z serwera tak, jak zwykłe odnośniki. Przesyłane dane są widoczne dla użytkownika, a rezultat działania formularza może być zapamiętany w zakładkach.

Użycie GET polecane jest szczególnie do tzw. zapytań idempotentnych, tzn. takich, które nie powodują efektów ubocznych, takich jak zmiana lub usunięcie jakichś danych na serwerze. Wejdź na stronę Google, wyszukaj coś i zobacz, jaką zmienną QUERY_STRING generuje wyszukiwarka. Ujrzysz ją po naciśnięciu przycisku „Szukaj” w obrębie URI skryptu wyszukującego, znajdującego się w Pasku adresu przeglądarki.

Jeśli formularz wysyłany jest metodą GET, to nie umieszczaj Query String w atrybucie action. Zamiast tego dodaj ukryte pola do formularza.

POST
Oznacza, że formularz wykonuje jakąś ważną akcję na serwerze, np. zalogowanie lub rejestrację użytkownika, dodanie artykułu, itp. Dane zostaną przesłane jako treść zapytania HTTP, przez co przesyłane dane będą niewidoczne dla użytkownika (choć to w żaden sposób nie gwarantuje bezpieczeństwa/poufności przesyłanych danych!). Stosowane głównie w przypadku wysyłania sporej ilości tekstu.

Bez określania atrybutu method dla elementu form domyślnie zastosowane zostanie żądanie GET.

Format danych (enctype)#

Atrybut enctype określa internetowy typ mediów dla danych, czyli sposób kodowania tych danych. Mogą to być następujące wartości:

Zastosowanie domyślnego typu mediów dla danych application/x-www-form-urlencoded powoduje, że przeglądarka w celu zgromadzenia zestawu danych do wysłania wykona następujące operacje:

Z kolei typ mediów multipart/form-data używany jest, gdy formularz wysyła na serwer dane binarne lub pliki – to jest gdy zawiera kontrolki pola wyboru pliku. W takim wypadku kodowanie application/x-www-form-urlencoded staje się wysoce nieefektywne.

Dane określone za pomocą multipart/form-data podzielone są na części. Każda część reprezentuje jedną kontrolkę. Części rozdzielone są ciągiem granicznym, złożonym z kilku znaków alfanumerycznych, i zakodowane w odpowiedni sposób, domyślnie jako czysty tekst text/plain. Jeśli w zestawie danych znajduje się kilka plików, wtedy dla wszystkich stosowany jest typ danych multipart/mixed. Wszystko to definiowane jest za pomocą odpowiednich nagłówków (content-type, content-disposition i content-transfer-encoding) z parametrami (boundary, name, filename i charset). Przykładowo:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
Content-Type: multipart/form-data;
 boundary=AaB03x

--AaB03x

Content-Disposition: form-data; name="imie"

Bodzio

--AaB03x

Content-Disposition: form-data; name="zdjecie";
 filename="bodzio.jpg"

Content-Type: image/jpg

Content-Transfer-Encoding: binary

...zawartość pliku bodzio.jpg...

--AaB03x--

Strona kodowa (accept-charset)#

Domyślnie dane z formularza przesyłane są przy użyciu takiej samej strony kodowej jaka określona została w dokumencie z formularzem. W pewnych przypadkach może się zdarzyć, że system odbierający dane (np. skrypt PHP lub program pocztowy) nie obsługuje znaków w przesyłanym formacie. W takiej sytuacji należy ujednolicić kodowanie dokumentu i systemu odbierającego dane, bo inaczej dane zostaną niewłaściwie zinterpretowane - dotyczy to głównie polskich znaków diakrytycznych.

Najprościej ustawić taką samą stronę kodową dokumentu z formularzem jaką obsługuje system odbierający, ale jest to nieeleganckie - cała reszta serwisu byłaby zapisana inaczej. Również zmiana kodowania systemu odbierającego dane z formularza może stwarzać problem, jeśli np. nie mamy dostępu do serwera.

W takiej sytuacji wystarczy zdefiniować, jakiej strony kodowej używa system odbierający dane, a przeglądarka podczas wysyłania formularza powinna automatycznie skonwertować cały tekst. Na przykład, jeśli nasza strona jest zapisana przy użyciu kodowania znaków iso-8859-2, ale wiemy, że system, do którego wysyłamy formularz używa kodowania utf-8, powinniśmy zadeklarować:

  1. —
  2. L
  3. K
  4. T'
  5. T
  6. A
  7. O
  8. Z'
  9. Z
  10. #
<form action="" accept-charset="utf-8"></form>

Niestety atrybut accept-charset nie jest panaceum na zachowanie prawidłowych polskich znaków diakrytycznych w prostych formularzach pocztowych. Nie wiadomo z jakiego systemu operacyjnego ani z jakiego programu pocztowego korzysta użytkownik, który będzie wypełniał formularz, a więc nie można jednoznacznie ustalić docelowej strony kodowej wysyłanych danych.

W chwili obecnej kodowanie UTF-8 stało się na tyle powszechne i uniwersalne, że problemy z kodowaniem powoli, ale sukcesywnie zanikają.

Pasek społecznościowy

SPIS TREŚCI AKTUALNEJ STRONY

Formularze (H1) Ogólne ramy formularza (H2) Adres docelowy (action) (H3) Metoda (method) (H3) Format danych (enctype) (H3) Strona kodowa (accept-charset) (H3)