Taeyo's ASP.NET
|
|
강좌 최초 작성일 : 2002년 12월 18일|
강좌 전 태오의 잡담> 메리 크리스마스~~ 새해에는 좋은 일만 가득하기를요~~~ ^^ ASP.NET TextBox Control
TextBox도 WebControl로부터 상속을 받는 다음과 같은 계층 구조를 갖는다. 그러므로, WebControl 클래스의 모든 기능을 상속 받아 그대로 사용할 수 있다.
TextBox 컨트톨이 가진 속성 중 가장 중요한 속성은 TextMode 로써, 이는 SingleLine, Password, MultiLine의 3 가지 모드를 제공한다. SingleLine은 일반적인 한 줄짜리 텍스트 박스를 나타내며, Password는 입력된 텍스트의 내용이 * 로 표시되는 한 줄짜리 텍스트 박스를, MultiLine 은 TextArea를 의미한다. MultiLine 모드의 경우에는 그 컨트롤의 사이즈를 설정하기 위해서 Rows, Columns 속성이나 Width, Height 속성을 사용한다. 일반적으로는 Rows와 Columns 속성을 사용하는 편이다.
다음 표는 TextBox 컨트롤이 제공하는 속성과 이벤트 중 알아두어야 할 일부를 정리한 것이다. 완전한 목록은 [VS.NET 도움말]을 참고하기 바란다. 여러분의 PC에 VS.NET이 설치되었다면 그 도움말(한글)의 바로가기 경로는 다음과 같다.
표에 나타난 대부분의 속성들은 상당히 직관적이기에 쉽게 그 역할을 이해할 수 있을 것이다. 필자가 이러한 기능들 중에서 강조해서 이야기하고 싶은 부분은 AutoPostBack 속성과 TextChanged 이벤트인데, 이 들에 대해서는 확실하게 이해하고 넘어갈 필요가 있다. AutoPostBack 속성은 위의 표에서 설명했듯이, TextBox 컨트롤의 Text 값이 변경될 경우, 변경 즉시 서버로 웹 폼을 PostBack 할 것인지를 지정하는 속성이다. 기본적으로 그 값은 false로 설정되어 있지만, 여러분은 그 값을 true로 바꿀 수 있으며, 그럴 경우 사용자가 텍스트의 값을 변경하는 즉시, 자동으로 폼은 서브밋 된다. 그리고, 서버에서는 기본적인 이벤트 처리와 함께 TextChanged 라는 이벤트 함수도 처리 된다. AutoPostBack 속성이 false로 설정되어 있는 상태에서는 TextBox 컨트롤의 Text 값이 바뀌어도 그 즉시 폼이 서버로 게시되지는 않으며, 이것이 우리가 일반적으로 작성해왔던 페이지 스타일이었음을 기억하라. 일반적인 경우, 웹 폼은 버튼 컨트롤의 클릭등에 의해서 서버로 전송되어진다. AutoPostBack 기능과 관련하여 여러분이 오해하기 쉬운 것이 하나 있는데, 그것은 TextChanged 이벤트의 처리 시점에 대한 것이다. 이 부분은 주의해서 생각할 필요가 있다. AutoPostBack가 true일 경우는 TextBox 컨트롤의 Text 속성의 값이 사용자에 의해 변경되는 그 즉시 서버로 웹 폼이 전송되고, TextChanged 이벤트 함수가 발생된다고 설명했기에, 혹 AutoPostBack 속성과 TextChanged 이벤트 사이에 어떤 관계가 있는 것처럼 받아들일지도 모르겠지만, 사실상 AutoPostBack은 단지 사용자가 TextBox의 값을 변경했을 경우, 무조건 폼을 PostBack 시키는 기능에 불과하다. 그리고, TextChanged 이벤트는 TextBox의 값이 사용자에 의해 변경되었다면 서버 측에서 그로 인해 발생, 처리되는 함수일 뿐이다. 사실상 둘 사이에는 아무런 연관도 없다. 즉, AutoPostBack 값이 false인 경우에도 TextBox 컨트롤의 Text 속성의 값이 사용자에 의해 변경되었다면 TextChanged 이벤트는 서버에서 처리 된다는 것이다. 단, 텍스트의 값이 변경되는 그 즉시 이벤트가 처리하는 것이 아니라, 버튼 컨트롤의 클릭등에 의해서 웹 폼이 서버로 전송되는 시점에 즉, PostBack 되는 시점에 서버에서 여러 가지 처리와 함께 TextChanged 이벤트 함수의 처리도 일어나는 것이다. AutoPostBack이 true로 설정된 경우는 TextBox의 값이 변경되면, 그 즉시 폼이 서버로 전송되어 TextChanged 이벤트가 처리되기에, 마치 텍스트 값 변경 즉시 이벤트가 발생하는 것처럼 보이지만 사실상 서버측의 모든 이벤트들은 폼이 PostBack 되어 서버에서 페이지를 다시금 실행할 시에 처리된다. ASP.NET은 서버측의 기술이라는 것을 다시 한번 상기하자. 클라이언트 측에서 TextBox의 값을 수정하였다고 해서, 그 즉시 서버가 자동으로 어떤 처리를 하는 것은 아니다. 폼의 내용을 서브밋 해야만 서버측의 처리가 시작되는 것이고, 그 처리 상황 시에 여러 가지 발생한 이벤트들도 함께 처리되는 것이다. 서버는 클라이언트의 반응에 그 즉시 대처할만한 충분한 능력을 가지고 있지 않다. 서버는 서버로 요청한 작업에 대해서만 관심을 가지며, 그러한 작업만을 열심히 수행한다. 즉, 서버로 폼을 서브밋 하거나, 특정 페이지에 대한 요청을 하지 않으면 서버는 클라이언트를 위해서 아무런 작업도 하지 않는다는 것이다. 이것은 여러분이 웹 프로그래밍을 한다면 언제나 기억해 두어야 할 사실이다. 아주 간혹 예외적인 기술(Remote Scripting이라는 기술)이 있기는 하지만, 99% 경우는 그렇다고 각인해 두기 바란다. 서버는 서버에게로 페이지의 실행요청이 들어오지 않는 한(PostBack을 통해서, 혹은 직접적인 페이지 요청에 의해서) 그 어떠한 작업도 수행하지 않는다. 이해가 어려운가? 어쩌면 필자의 설명이 여러분을 헛갈리게 할 수 있다는 생각도 든다. 이런 경우 회의감이 들기는 하지만, 해결방법이 없는 것은 아니다. 그 방법은 바로 적절한 예제를 같이 해보는 것이다. 프로그래밍은 사실 말로써 이해하는 학문이라기 보다는 코딩을 통해서 이해하는 학문이다. 그렇다면, 이 시점 적절한 예제가 우리에게는 필요하다. 여러분의 웹 어플리케이션인 TaeyoAspNet에 새로운 웹 폼 페이지를 하나 추가하자. 필자의 경우는 TextBoxes.aspx라는 페이지를 하나 추가했다. 페이지를 추가했다면 다음과 같이 페이지를 구성하도록 하자. 3개의 TextBox와 1개의 Label을 웹 폼에 추가하는데, 각 컨트롤들의 속성 설정은 다음의 표를 참고하도록 하자.
컨트롤들의 속성 값들이 모두 설정되었다면, 이제 각각의 컨트롤에 이벤트 함수 처리를 추가해 보도록 하자. 먼저 웹 폼 디자이너 모드에서 txtSingle라는 id를 갖는 TextBox 컨트롤을 더블 클릭 해 보자. 그러면, VS.NET은 코드 비하인드 페이지로 전환되면서 다음과 같은 코드를 추가해 줄 것이다. 이 함수는 txtSingle이라는 TextBox 컨트롤의 값이 사용자에 의해 변경되었을 경우, 서버에서 처리되는 함수이다.
코드 비하인드 구역에서 우선 먼저 클래스 내에서 전역적으로 사용할 string 변수를 하나 선언해 주도록 하자. 클래스의 선언 밑으로 컨트롤들이 선언된 구역이 있을텐데, 그 밑에 다음의 코드를 추가한다. private string msg = ""; 그리고, 자동으로 생성된 이전 이벤트 함수 내에 다음과 같은 코드를 추가하자.
다시 웹 폼 디자인 모드로 돌아가서, 나머지 2개의 TextBox도 더블 클릭하여 각각의 TextChanged 이벤트 함수에 다음과 같은 코드를 작성해 보자.
작성된 전체 비하인드 코드 페이지의 코드는 다음과 같을 것이다.
작성된 코드에 불만이 새록새록 생기려 해도 일단 코드를 모두 작성하였다면 페이지를 컴파일하고 실행해서 결과를 먼저 확인해 보도록 하자. 코드에 대한 설명은 결과화면을 테스트 한 다음에 이야기할 것이다. 페이지가 브라우저에 로드 되면 초기 모습은 다음과 같을 것이다.
위와 같은 결과를 얻었다면 이제 같이 테스트를 해보도록 하자. 우선 Single Line TextBox에 "Taeyo”라는 값을 넣어보자. 그리고, Tab 키를 사용하거나 마우스를 클릭하여 Password 컨트롤쪽으로 포커스를 이동시켜 보자. Single Line 텍스트박스에 데이터를 입력하고, Password 컨트롤쪽으로 포커스를 이동시키는 순간, 폼은 서브밋 될 것이고 PostBack이 발생할 것이다. 그리고, 페이지 하단의 Label 컨트롤에는 다음 그림처럼 이벤트의 결과가 나타날 것이다.
텍스트 박스에 값을 넣고, 포커스를 이동한 경우 Single Line 텍스트박스의 AutoPostBack 기능에 의해 폼은 서버로 PostBack 된 것이다. 이것이 AutoPostBack의 역할임을 기억하자. 이제, Password 컨트롤에 적절히 값을 입력한 다음 다시금 포커스를 MultiLine 텍스트박스로 옮겨보자. Password 컨트롤도 AutoPostBack 이 설정되어져 있으므로, 포커스 이동 시 폼은 서브밋 될 것이고, 서버에서는 값이 변경된 Password 컨트롤의 TextChanged 이벤트가 발생하여 그 결과가 Label 컨트롤에 나타날 것이다. 다음 그림처럼 말이다.
출력되는 결과에서는 Password 컨트롤에 입력한 이전 값이 사라져 있을 것이다. 놀랄 필요는 없다. Password 컨트롤은 기본적으로 보안적인 이유로 인해 그 값을 유지하지 않는다. 그것이 기본적인 그 컨트롤의 특성이기에 그런 것일 뿐 잘못된 것은 아니다. 여기서 잠깐 이야기를 덧붙이자면, 여러분이 컨트롤에 입력한 값들은 현재 눈에 보이던 보이지 않던 내부적으로 그 값을 가지고 있다는 것을 알아두기 바란다. 브라우저에서 마우스 우측 클릭하고 [소스 보기]를 선택하면 HTML 소스를 볼 수 있는데, 그 소스에는 <input type="hidden" name="_VIEWSTATE" ..> 와 같은 컨트롤이 있고, 그 안에 쉽게 알아보기 힘든 난잡한 문자열이 들어있는 것을 볼 수 있을 것이다. 다음 그림처럼 말이다.
이 값들은 폼 내에 존재하는 컨트롤들의 기존 값을 인코딩한 문자열이다. 이것은 Base64 라는 규칙에 의해 인코딩 되어있고, 서버는 폼이 서버로 전송될 경우(즉, PostBack될 경우) 이 값들을 내부적으로 자체 디코딩하여 원래의 값을 얻어낼 수 있다. VIEWSTATE에 대해서는 이후 자세히 알아보게 될 것이지만, 여기서는 이 감춰진(Hidden) 컨트롤을 통해서 서버가 각 컨트롤들의 이전 값들을 알아낼 수 있다는 사실만 기억하자. 고로, Password 컨트롤의 값도 우리의 브라우저 결과화면에서는 볼 수 없지만, 실은 Hidden 컨트롤 내에 인코딩되어 존재하고 있으며, 서버는 여전히 Password 컨트롤의 이전 값을 알 수 있는 것이다. 다시금 테스트를 이어가자. 이번에는 MultiLine 텍스트박스에 맘에 드는 글을 입력해 본다. 적절히 데이터를 입력한 다음, 포커스를 다른 컨트롤로 옮기는 순간, MultiLine 텍스트박스의 AutoPostBack 기능에 의해 페이지는 PostBack이 될 것이고, 서버는 그 결과로 다음과 같은 결과 문자열을 Label 컨트롤에 나타내 줄 것이다.
재미있는 것은 이번의 결과로는 두 줄의 결과 문자열이 출력되었다는 것이다. 이해가 안 가는가? 이해가 간다고 말하고 있는 당신은 명석한 종족일 것이며, 이해가 안가는 몇몇 분은 똑똑한 편에 속하는 종족이다. 뭐 나름대로의 개그다. -_-+ 왜 이러한 현상이 생기는지 알아보자. 사실은 이러한 결과를 나타내기 위해 소스에 msg 라는 문자열 변수를 사용했던 것이기도 하다. 여러분이 MultiLine 텍스트박스에 데이터를 입력하고, 포커스를 이동시키면 그 순간 AutoPostBack에 의해서 분명 서버로의 PostBack은 일어나고, MultiLine 텍스트박스의 TextChanged 이벤트 또한 처리된다. 하지만, 그것이 전부인가? 잘 생각해 보라. 잘 생각해 보면 password 컨트롤의 값도 변경되었음을 알 수 있다. 물론, 우리는 그 값을 바꾼 적이 없다. 페이지 로드 시, Password 컨트롤의 기본적인 특성에 의해 컨트롤에서 값이 저절로 사라진 것일 뿐이다. 하지만, 서버는 여전히 그 Password 컨트롤의 기존 입력 값을 알고 있다는 사실이 중요하다. 해서, 우리는 단지 MultiLine 텍스트박스에 값을 입력하고, AutoPostBack을 통해 서버로 폼을 전송했지만 그 당시 Password 컨트롤의 값도 기존의 값이 아닌 공백의 값으로써 바뀐 것으로 취급된다는 것이다. 폼이 서브밋되는 순간, 서버는 _VIEWSTATE 라는 hidden 컨트롤에 구성되어져 있는 값을 통해서 각 컨트롤의 기존 값들을 읽어 들인다. 그 안에는 기존의 컨트롤들의 값이 모두 들어있다. 서버는 이를 통해서 기존의 값들을 먼저 얻어내고, 새로이 입력된 컨트롤의 값들과 기존 값들을 비교하기 시작한다. 만일, 기존의 값과 현재 입력된 값 중에 차이가 있는 컨트롤이 있다면 서버는 그 컨트롤들의 TextChanged 이벤트 함수를 실행하는 것이다. 고로, 우리가 MultiLine 텍스트박스에만 값을 입력하고 AutoPostBack 하였다 하더라도, 서버에서는 이전 값과 일치하지 않는 Password 컨트롤과 MultiLine 텍스트박스 컨트롤 모두의 TextChanged 이벤트를 처리하는 것이며, 그 결과로 지금 여러분이 보고 있는 결과문자열이 구성되어 Label 컨트롤에 출력된 것이다. 이러한 이벤트 처리 구조를 이해하는 것은 매우 중요하다. 이것이 ASP.NET의 전반적인 이벤트 처리 구조이기 때문이다. 좋다. 어느 정도 이해가 되기 시작했다면 이제 그림을 통해서 이 사실을 확실히 머리 속에 저장해 보도록 하자. 다음 그림들은 우리가 테스트한 3 단계 모두를 나타내고 있다. 먼저 1단계 그림부터 보도록 하자.
페이지가 로드된 후, 사용자가 txtSingle 컨트롤에 데이터를 입력하고, 포커스를 옮기면 그 순간 AutoPostBack에 의해서 서버로 웹 폼은 PostBack 된다. 위의 그림의 (1), (2), (3)은 그러한 동작을 나타내고 있으며, 폼이 서버로 전송될 경우, ASP.NET 페이지는 동적으로 구성되면서 (4) 단계를 거치게 된다. 페이지의 첫 로드 시에는 모든 컨트롤에 값이 부여된 것이 없었기에, 현재의 경우 컨트롤의 값이 바뀐 것은 txtSingle 컨트롤 뿐이라는 것을 서버는 알 수 있다. 이러한 검사(4)에 의해 서버에서는 txtSingle 컨트롤의 (5)TextChanged 이벤트 함수만이 처리되며, 그 결과가 Label 컨트롤에 출력된다.
이제는 사용자가 비밀번호를 입력하는 경우를 보자. 사용자가 비밀번호를 입력하고, 포커스를 이동하면, 그 순간 AutoPostBack에 의해서 서버로 웹 폼은 PostBack된다. 위의 그림의 (1), (2), (3)은 그러한 동작을 나타내고 있으며, 폼이 서버로 전송될 경우, ASP.NET 페이지는 역시 (4) 단계를 거치면서 페이지를 구성하게 된다. 기존의 txtSingle 컨트롤의 값은 그대로 모두 "Taeyo”라는 값을 유지하고 있으므로, 이 컨트롤의 TextChanged 이벤트는 동작하지 않으며, 값이 변경된 txtPassword 컨트롤만이 단계 (5)에 의해서 자신의 TextChanged 이벤트 처리를 수행한다. 그 결과는 역시 Label 컨트롤에 나타나게 된다. 이번에는 마지막 단계인 txtMulti 컨트롤에 데이터를 넣고 포커스를 이동할 경우를 살펴보도록 하자.
사용자가 txtMulti 컨트롤에 적절히 데이터를 입력하고 포커스를 이동하면, 이전과 마찬가지로 폼은 AutoPostBack을 수행할 것이며, 서버에서는 단계 (4)를 수행해서 어떤 컨트롤들의 값이 변경되었는지를 검사할 것이다. 이번에는 txtPassword와 txtMulti 2개의 컨트롤의 값이 변경되었음을 서버는 알 수 있다. 물론, txtPassword는 사용자의 입장에서는 변경하지 않았지만, 결과적으로는 변경된 것이니 말이다. 해서, 이번의 경우에는 2개의 컨트롤 모두의 TextChanged 이벤트가 수행되어지며, 그 결과가 Label 컨트롤에 출력된다. 사실은 이러한 결과를 나타내기 위해 소스에 msg 라는 문자열 변수를 사용했던 것이다. 각각의 이벤트가 수행될 때 마다 msg라는 변수에 그 이벤트가 처리되었다는 문자열을 추가하여, 그로 인해 출력되는 문자열 결과를 통해서 웹 폼이 이러한 이벤트 처리 흐름을 갖는다는 사실을 쉽게 이해할 수 있도록 하기 위해서 말이다.
msg += "txtMulti 컨트롤의 값이 " + txtMulti.Text + "로 변경되었습니다.<br>"; msg += "txtMulti 컨트롤의 값이 " + txtMulti.Text + "로 변경되었습니다.<br>"; 라는 의미는 msg = msg + "txtMulti 컨트롤의 값이 " + txtMulti.Text + "로 변경되었습니다.<br>"; 와 같은 의미로써 기존에 존재하는 msg 라는 변수 값에 현재의 문자열을 추가하는 것을 의미한다. 즉, 단계 (5) 에서는 먼저 발생한 txtPassword_TextChanged 이벤트 함수에 의해 msg 라는 변수에는 "txtPassword 컨트롤의 값이 로 변경되었습니다<br>"라는 값이 저장되며, 이것은 Label 컨트롤에 쓰여지도록 준비될 것이다. 그리고, 이어서 txtMulti_TextChanged 함수도 수행될 것이며, 이로 인해 msg 변수는 기존의 값에 현재의 문자열이 추가된 형태로 저장된다. 그리고, 이렇게 작성된 문자열은 Label 컨트롤에 쓰여지도록 결과 HTML을 준비하게 된다. 해서 여러분은 결과 화면에 이러한 문자열이 합쳐진 결과를 보게 된 것이다. 이해력이 빠른 독자라면 이러한 내용을 이토록 구체적으로 설명하는 필자를 이해할 수 없다고도 말할 수 있겠으나, 이 개념은 중요하다. 언제나 기초가 중요하다는 것을 강조하고 싶은 필자로서는 지금 한 두 페이지의 지면을 더 할애해서라도 이러한 설명을 구체적으로 하는 것이 중요하다고 생각했다. 비록 약간의 핀잔을 들을지라도 말이다.(설마 진짜로 핀잔을? 오히려 칭찬을~) 그럼 이번에는 3개의 TextBox 컨트롤들의 AutoPostBack 속성을 false로 지정해 보도록 하자. 모든 컨트롤의 AutoPostBack 값이 false로 설정되면, 웹 폼은 추가적인 버튼 컨트롤 등의 도움 없이는 페이지를 PostBack 할 수가 없다. 그러하니, 폼에 버튼 컨트롤도 하나 추가해 보도록 하자. 약간 수정된 웹 폼의 모습은 다음과 같을 것이며, 각 TextBox 컨트롤들의 AutoPostBack 속성 값은 모두 false인 상태일 것이다. (버튼 컨트롤의 ID는 기본값인 Button1로 그대로 두도록 하자)
이제, 페이지를 실행하여 결과를 한번 확인해 보도록 하자. 다음처럼 디자인 모드에 마우스 우측클릭을 하고 [브라우저에서 보기]를 선택하도록 하자.
그러면, 다음과 같은 결과화면이 나타날 것이다.
초기화면은 이전과 크게 다를 것이 없어보인다. 하지만, 기능적으로는 상당히 다르다. 각각의 텍스트박스에 데이터를 적절히 입력해 보자. 각각의 텍스트 박스에 값을 입력하고, 포커스를 이동했을 때, 이전처럼 폼이 AutoPostBack 되는 일은 발생하지 않는다. 그 기능을 여러분이 꺼두었기 때문이다. 이제 폼은 버튼과 같은 컨트롤이 없이는 폼의 내용을 서브밋할 수 없게 되었다. 이제, 버튼을 눌러 폼을 서브밋 해 보자. 그러면, 다음과 같은 결과화면을 볼 수 있을 것이다
이미 이벤트의 처리절차에 대한 지식을 가지고 있는 여러분이라면 위의 결과에 승복할 수 있을 것이다. 각각의 텍스트 박스에 기입(변경)된 내용들은 버튼이 클릭되어 서브밋 될 경우, TextChanged 이벤트의 수행에 의해 출력된 것이라는 사실을 말이다. 그렇다. 그러한 여러분이야말로 소스 작성에 최선을 다하고, 그 결과에 승복할 줄 아는 세상을 만들어 나가는 개발자들인 것이다. 자. 어느 정도 내공이 쌓인 여러분이기는 하지만, 아직 강호에 뛰어들기에는 부족함이 있다. 해서, 이번에는 그러한 내공을 조금 더 증진시키는 시간을 가져보려 한다. 이벤트의 처리절차에 대해 약간의 이해력이 생겼으니 그 이야기에 살을 조금 더 붙여보려 하는 것이다.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
