Do jakiej kwalifikacji zawodowej należy to pytanie?

To pytanie pochodzi z kwalifikacji INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych. Wymagana w zawodach: Technik informatyk, Technik programista.

W jakim zawodzie przydaje się ta wiedza?

Wiedza ta jest potrzebna w zawodach: TECHNIK INFORMATYK oraz TECHNIK PROGRAMISTA.

Gdzie mogę przećwiczyć więcej pytań z kwalifikacji INF.03?

Więcej pytań z kwalifikacji INF.03 znajdziesz na Zawodowe.edu.pl - darmowa baza pytań CKE z symulatorem egzaminu.

Zamieszczony kod HTML formularza zostanie wyświetlony przez przeglądarkę w sposób: … - INF.03 | Egzaminy Zawodowe | Egzaminy Zawodowe

Dokładnie tak powinien wyglądać ten formularz! Zwróć uwagę, jak HTML interpretuje znaczniki <br> – one wymuszają przejście do nowej linii, więc w kodzie wyjściowym każda sekcja obowiązków pojawi się osobno, pod sobą. To, że jeden z checkboxów ma atrybuty disabled oraz checked, powoduje, że jest domyślnie zaznaczony, ale nie można go odznaczyć ani zaznaczyć ponownie – to ważny niuans, bo czasem zapomina się, że disabled nie oznacza tylko „wyszarzony”, ale też „nie bierz udziału w wysyłaniu formularza”. Takie wykorzystanie checkboxów jest powszechne, szczególnie jeśli chcesz pokazać użytkownikowi pewne stałe informacje (np. obowiązek, którego nie można uniknąć). Z mojego doświadczenia, bardzo często w praktycznych projektach „disabled” stosuje się np. przy wymaganych oświadczeniach, gdzie użytkownik ma tylko do wglądu informację, że coś już jest włączone i nie może tego zmienić. No i jeszcze – checked przy pisaniu kodu powoduje, że checkbox jest domyślnie zaznaczony, co jest zgodne z kodem źródłowym. Same nazwy pól (czyli atrybuty name i value) zostaną wysłane do serwera tylko dla tych pól, które nie są disabled i użytkownik je zaznaczył. To też jest bardzo praktyczna rzecz, bo pozwala precyzyjnie sterować tym, co trafia do backendu. Moim zdaniem taka forma zapisu formularza to dobry punkt wyjścia do dalszej rozbudowy – łatwo dodać tutaj walidację, obsługę JavaScript czy zastosować style CSS. Trzymanie się tej składni ułatwia też potem pracę zespołową, bo jest czytelna i zgodna z oczekiwaniami innych programistów. Podsumowując, wybrałeś opcję najbliższą temu, co wyświetli przeglądarka na bazie danego kodu HTML – i to jest podejście zgodne ze standardami, doceniane w branży.

Przy ocenie, jak przeglądarka wyświetli formularz HTML, warto mieć na uwadze, że przeglądarki internetowe trzymają się dość sztywno tego, co wynika bezpośrednio z kodu źródłowego. Bardzo typowym błędem jest nadmierne skupienie się na samych polach wyboru czy zawartości formularza, bez uwzględnienia układu wynikającego z użycia znaczników <br> – to właściwie one decydują o tym, gdzie pojawiają się nowe linie. Ktoś może sądzić, że kolejność checked lub disabled zmieni znacząco wygląd – ale to nieprawda, bo atrybuty te wpływają na stan i interaktywność, a nie na rozmieszczenie. W jednej z błędnych propozycji pomieszano, które checkboxy są zaznaczone, a które nie, co prowadzi do przekłamań względem rzeczywistego kodu. Zdarza się też, że przy kopiowaniu kodu pomija się disabled lub checked przy konkretnym polu i całość wygląda inaczej niż powinna – tak po prostu nie działa przeglądarka. Ważne jest też zrozumienie, że disabled powoduje, iż pole jest wyszarzone i nie można na nim operować, natomiast checked przy polu checkbox ustawia je domyślnie jako zaznaczone. Pominięcie <br> po polu tekstowym sprawia, że kolejne elementy formularza lądują w jednej linii – co w praktyce bardzo rzadko się zdarza, bo narusza czytelność, a kod źródłowy wyraźnie tego nie przewiduje. Z mojego doświadczenia widziałem wiele formularzy, które przez nieuwagę programistów wprowadzały użytkownika w błąd przez złe rozmieszczenie elementów – nie chodzi tylko o „ładny wygląd”, ale też o funkcjonalność i dostępność. W praktyce branżowej trzymanie się tego, co wynika z kodu HTML, to podstawa, bo zapewnia przewidywalność działania na wszystkich platformach. Dobrym zwyczajem jest zawsze sprawdzić, jak kod wyświetla się w przeglądarce i porównać go z tym, co chcieliśmy osiągnąć. Dzięki temu unikamy nieporozumień i nieprawidłowych założeń, które mogą prowadzić do błędów zarówno w warstwie frontendowej, jak i podczas przetwarzania danych na serwerze.

Odpowiedzi

Informacja zwrotna