[HTML] Input & Form Tag

yongkini ·2021년 9월 4일
0

HTML

목록 보기
7/12
post-thumbnail

Input tag and Form Tag

: 지난번 input 태그에 대한 포스팅에 이어서 form 태그 내에서 input 태그를 써봄으로써 input 태그에 대해서 심화 공부를 해보고자 한다. 오늘은 간단한 로그인, 회원가입, index 페이지를 만들어보면서 (서버와의 소통없이), input 태그의 속성들과 실제로 다양한 type의 input 요소들이 form 태그 내에서 어떤 기능을 하는지에 대해서 정리하고자 한다.

  • 먼저 위와 같이 form 태그, input 태그(권장하는 사항은 아니지만, 연습삼아 테이블 태그로 레이아웃을 구성해봤다)를 사용하여 간단한 login form을 만들어봤다.

    로그인 폼 관련 code
  • 위에는 실제 내가 타이핑한 코드인데, 핵심부분을 설명하면서 input 태그, form 태그에 대해서 공부해보고자 한다.

  • 먼저, 전체는 form 태그의 자식요소로 묶여져 있는데, 그러한 form 태그의 속성을 보면, action과 method를 볼 수 있다. action 속성은 실제로 form 태그를 제출할 때 유저가 입력한 데이터를 어디로 보낼지 URI 정보를 넣는 곳이다. 하지만, 아직 서버와의 소통 로직을 구현하지 못하는 단계이기에 내가 만들어놓은 다른 html 파일인 index.html을 적어두었다. 그 다음으로 method 속성은 GET, POST 등을 쓸 수 있는 속성인데, GET을 쓰면 URL과 ? 구분자와 함께 전송되어 실제로 URL 검색창에 보이게되고, POST를 통해 보내면 보이지 않고 보내지게 된다.

    " 이러한 모든 속성은 선택적이지만 action 속성과 method 속성은 필수적으로 설정해야 한다." by MDN

  • 다음으로 대부분의 input 태그를 label 태그와 한묶음처럼 사용한 것을 볼 수 있고, 각각의 묶음에서 input 태그의 id와 label 태그의 for 속성이 일치하는 것을 볼 수 있다. MDN에 따르면, 둘을 매핑시켜놓는 것의 장점은 해당 라벨을 클릭했을 때, 예를 들어, 위에서 아이디 부분을 클릭했을 때, 해당 라벨에 매핑되는 위젯(input)에 자동으로 커서가 올라가지는 기능이다.
    ** 위의 코드에서는 라벨 태그와 인풋 태그를 별개로 써줬지만, 만약에 라벨 태그의 자식요소로 인풋 태그를 써준다면 for 속성을 굳이 써주지 않아도, 알아서 둘이 매핑된다.

  • 다음으로 input 요소의 속성들에 대해서 알아보면,

    • autocomplete = "off" 부분이 있는데, 본래 autocomplete="on"이 디폴트여서 내가 이전에 이 사이트에 방문해서 아이디에 '0715yk'를 써놨더라면 그 데이터를 바탕으로 자동완성 기능을 제공한다.
    • placeholder 속성은 위에서 아이디 input, 그리고 패스워드 input에 회색으로 아이디, 패스워드가 각각 적혀있는 것을 볼 수 있는데, 이처럼, placeholder는 유저들에게 이 입력창에 어떤 식으로 입력을 하면 된다라는 것을 알려주는 지침과 같은 역할을 해준다. 따로 css를 적용해서 색깔, 크기 등을 변경할 수도 있다.
    • required 속성은 boolean 타입의 속성으로 써주기만 하면 적용되는데, 써주면, 필수 입력사항으로 취급된다. 그래서 만약에 아이디를 입력하지 않고, 로그인 버튼을 누르면 입력을 촉구하는 팝업이 뜨게된다(툴팁이라고 하는데, 브라우저마다 다르다). # 툴팁 예시
    • type="submit" input에서 value 속성은 button 태그와 비교해보면, 버튼 태그는 빈요소가 아니기에 그 콘텐츠로 버튼 태그 내에 어떤 콘텐츠를 넣을지 정할 수 있다. 따라서, 이미지 태그를 넣어줄 수도 있고, 다양한 콘텐츠를 넣을 수 있다. 그러나, input 태그는 value에 문자열만 입력이 가능하며 이렇게 value에 적어준 문자열은 input type="submit"의 버튼내 콘텐츠가 된다.
      **submit 타입이 아닌 input 태그에 value를 써주면, 해당 input의 실제 값이 된다. 예를 들어, 위에 hidden 타입의 인풋에 name을 userId로 하고, value를 지정해놓은 값(예를 들어, '124')으로 해주면, 서버에서 데이터를 받을 때 userId : '124'의 형태로 전달받는다.
    • name 속성은 해당 input의 '키(key)'를 정의해주는 속성이라고 할 수 있다. 서버로 데이터를 보낼 때, 키-값 형태로 데이터를 보내게 되는데, name부분에 '키'를 정의해주고, 실제 유저가 input에 타이핑한 내용이 value(값)이 되는 것이다.
    • id, class는 전역속성으로 input의 id는 앞서 말했듯이 label 태그의 for 속성과 매핑된다.
  • 다음으로 위의 로그인 폼에서 signup 버튼을 누른 화면을 살펴보면 이러하다.

    # 회원가입 폼
  • 위의 입력폼 또한 form 태그로 전체를 감쌌고, 각각의 input은 method="GET" 요청을 통해서, 만약에 signup 버튼을 누르면 아까 봤던 login 폼 페이지로 이동되면서 해당 URI에 파라미터로 전달된다. 여기서는 radio type input과 select 태그를 써봤고, date type input도 새롭게 사용해봤다.

    # select 태그
  • 위처럼 셀렉트 태그를 누르면 option에 세팅해놓은 프로그래밍 언어들이 팝업된다. 이중에 하나를 선택할 수 있고(multiple 속성을 적어주면 다중 선택도 가능하다), 선택한 option에 있는 콘텐츠(option에 value를 주면 콘텐
    츠와 value(값)을 다르게 줄 수도 있음. 예를 들어, C++을 선택해도, 서버로 보낼 때는 "lang" : "씨쁠쁠" 이렇게 키-값 형태로 보낼 수 있다는 것)가 서버로 보내지게 된다.
    ** 맨위에 '언어를 선택해주세요'와 그 옆에 체크 표시를 보면, 맨위에 option에 disabled, selected 속성이 주어진 것을 알 수 있다. disabled는 해당 옵션을 선택하지도, 서버에 보내지도 못하게 해놓는 속성이고(이와는 약간 다른 readonly가 있는데, readonly는 유저가 선택할 수 없지만, 서버로 보내질 때 disalbed와 다르게 보내지는 속성이다), selected는 해당 옵션을 디폴트로 선택시켜놓는 속성이다(checkbox의 경우 checked라는 유사한 속성이 있듯이).

  • 그 위에 포지션은 radio 타입을 이용해서 작성했는데, 굳이 radio를 이용한 이유라면 보통 radio 타입을 통해 상호 배타적인 선택지를 선택하도록 하기 때문이다. 물론 프론트 개발, 백엔드 개발이 서로 배타적이지 않지만(남, 녀처럼 한쪽에 해당되면 다른 한쪽에는 해당될 수 없는 개념), 한쪽을 선택하도록 유도해야한다는 측면에서 관습적으로 쓰이는 radio를 썼다. 이에 반해, 우리가 아는 checkbox는 주로 배타적이지 않은, 다양한 선택지에 다중으로 해당될 수 있는 선택을 유도한다. 이 때, radio의 name은 둘다 똑같이 설정해줘야한다.

  • 위와 같이 둘을 똑같이 설정해줘야 둘중하나만 선택해서 서버로 보낼 수 있도록 한다. radio의 경우 value에 있는 값이 서버로 보내지는 값이 된다.

  • 마지막으로 회원가입 후에 로그인 폼으로 와서 방금 회원가입한 페이지에서 가져온 정보를 바탕으로 로그인을 하면 다음과 같은 페이지가 나오도록 했다.

  • 이는 회원가입 폼에서 받은 정보를 로그인 페이지로 URI 파라미터로 보내준 다음에 실제로 그 정보로 로그인을 하면 다시 그 정보를 URI 파라미터로 index.html로 보내줘서 이렇게 페이지에 출력하도록 한 것이다. 물론, 로그인 및 회원가입 페이지를 만들 때는 서버와의 인터랙션, 토큰화, DB 저장 등 다양한 로직이 추가되겠지만(method도 GET으로 할 수 없다), HTML의 form, input, uri 파라미터 만을 이용해서 구현하고자 이렇게 했다.
    ** GET요청은 주로 드러나도 되는 정보를 전송할 때 쓰고, POST 요청은 비밀번호 같은 중요 정보를 서버에 드러내지 않은채로 보낼 때 쓴다. 그러나, POST 요청에도 암호화 등의 로직 적용이 필요하다(보안면에서 POST 요청만으로 완벽하지는 않다)

profile
완벽함 보다는 최선의 결과를 위해 끊임없이 노력하는 개발자

0개의 댓글