org.springframework.web.servlet.mvc
Class AbstractFormController
요청으로부터 폼 빈을 자동으로 채워주는 폼 컨트롤러이다. 요청마다 새로운 빈 인스턴스를 사용하거나, sessionForm 프로퍼티가 true로 설정되어 있을 경우, 동일한 빈 인스턴스를 사용한다.
이 클래스는 SimpleFormController와 AbstractWizardFormController와 같은 프레임워크의 하위 클래스들과 사용자가 제공하는 사용자 정의 폼 컨트롤러를 위한 기본 클래스이다.
폼 입력 뷰와 전송 후 뷰 모두 프로그램에서 제공되어야 한다. 환경 설정 프로퍼티를 사용해 이러한 뷰들을 제공하려면 SimpleFormController를 참조하여라.
하위 클래스들에서는, 폼 뷰를 마련하고 show Form과 전송 요청 처리를 위해 processFormSubmission을 재정의할 필요가 있다. 후자의 경우, 타입 불일치와 같은 바인딩 에러들은 제공된 "errors" 홀더를 통해 보고될 것이다. 추가적인 사용자 정의 폼 유효성 검사의 경우, BaseCommandController로부터 상속된 validator 프로퍼티를 사용해 동일한 "errors" 인스턴스를 통해 보고될 수 있다.
이 컨트롤러를 Struts의 Action과 비교해보면, Spring의 경우, Struts의 'ActionForm' 처럼 프레임워크에 종속되는 클래스를 구현하지 않고도 일반적인 JavaBeans나 데이터베이스 백엔드 JavaBeans를 사용할 수 있다. Date, Locale, 어플리케이션만의 고유 타입이나 복합 타입과 같이 JavaBeans의 보다 복잡한 프로퍼티들도, java.beans.PropertyEditor를 통해 표현 및 컨트롤러로의 전송이 가능하다.
작업 흐름
1. 컨트롤러는 새로운 폼에 대한 요청을 받는다 (대개 GET 방식이다).
2. formBackingObject()를 호출한다. 이 메소드는 디폴트로 commandClass 프로퍼티에 지정된 인스턴스를 반환한다. 그러나, 이것 역시 데이터베이스로부터 추출된 객체를 받는 것처럼 재정의 될 수 있다 (이는 대개 폼을 사용하여 수정될 필요가 있는 정보일 것이다).
3. initBinder()를 호출한다. 이 메소드를 통해 사용자는 커맨드 클래스의 특정 필드에 대한 사용자 정의 editor를 등록할 수 있다. 예를 들면, 이 과정을 통해 특정 로케일의 날짜 정보를 String 타입으로 보여줄 것이다.
4. bindOnNewForm이 true로 설정되어 있을 경우, 초기 요청 파라미터들을 가지고 새로운 폼 객체에 값을 채우는데 ServletRequestDataBinder가 적용되며, onBindOnNewForm(HttpServletRequest, Object, BindException) 콜백 메소드가 호출된다.
주: 이 시점에서는 부분적인 바인딩을 허용하기 위한 정의된 어떠한 Validator들도 적용되지 않는다. 그러나, (DataBinder.setRequiredFileds(String[]) 처럼) initBinder()를 통해 적용되는 사용자 정의 Binder는 여전히 적용된다. 그러므로, 만약 bindOnNewForm=true와 initBinder()를 정의해, Validator 대신 필드 유효성 검사를 수행하게 되면, 새로운 폼에 몇몇 필드들만이 채워지게 되어, 잠재적인 바인딩 에러를 발생시켜 errors 객체들을 채우게 될 경우가 있다. 바인딩 에러를 보여주는 뷰에서는 초기 폼 뷰를 보여주는지 일련의 결과를 보여주는지를 판단하는 기능을 갖출 필요가 있다. 이리하면, 전자의 경우에 대한 에러를 보여주는 사태를 방지할 수 있다.
5. showForm()을 호출한다. 이 메소드는 보여질 View를 반환한다 (대개 이 뷰는 폼을 보여주는 뷰일 것이다). 이 메소드는 하위 클래스에서 반드시 구현되어야 한다.
6. showForm()을 구현한 곳에서는 referenceData()를 호출한다. 이 메소드를 구현하여 폼 편집 시 필요한 관련 레퍼런스 데이터를 제공할 수 있다 (즉, Locale 객체 List를 제공해 사용자가 폼에서 이들 중 하나를 선택하도록 할 수 있다).
7. Model이 노출되고 뷰가 보여진다. 사용자는 폼에서 값을 채워나갈 수 있게 된다.
8. 컨트롤러는 폼 전송 요청을 받는다 (대개 POST 방식). 폼 전송을 감지하는데 있어 서로 다른 방법을 사용하려면 isFormSubmission() 메소드를 재정의 한다.
9. 만약 sessionForm이 설정되지 않았다면, formBackingObject()가 호출되어 폼 객체가 추출된다. sessionForm이 설정되어 있다면, 컨트롤러는 세션에 이미 바인딩 된 커맨드 객체를 찾으려 시도한다. 만약 어떠한 객체도 발견하지 못할 경우, 컨트롤러는 handleInvalidSubmit()을 호출한다. 이 메소드는 디폴트로 새로운 폼 객체를 생성하고 폼 재전송을 시도한다.
10. 현재 요청 파라미터들로 폼 객체를 채우는데 ServletRequestDataBinder가 적용된다.
11. onBind(HttpServletRequest, Object, Errors) 메소드를 호출한다. 이 메소드를 사용하면 바인딩 후, 유효성 검사 전에 사용자가 정의한 작업들을 수행할 수 있다 (예를 들면, 직접 요청 파라미터들을 빈 프로퍼티에 설정하는 것을 들 수 있다).
12. 만약 validateOnBinding이 설정되어 있다면, 등록된 Validator가 호출된다. Validator는 폼 객체 프로퍼티들을 검사하고 전달받은 Errors 객체를 통해 대응되는 에러들을 등록한다.
13. onBindAndValidate() 메소드를 호출한다. 이를 통해 사용자는 바인딩과 유효성 검사 이후 사용자 정의 작업을 수행할 수 있다 (예를 들면, 직접 요청 파라미터들을 바인딩 하여 Validator를 통해서가 아니라 직접 검사한다).
14. processFormSubmission() 메소드를 호출하여 전송을 처리한다. 이 메소드는 하위 클래스에서 구현되어야 한다.
세션 폼 모드의 경우, 세션에 존재하는 폼 객체 없이 전송하는 것은 유효하지 않으며 이는 브라우저에 의해 재전송/새로 고침하는 경우와 같다. 그런 후, handleInvalidSubmit() 메소드가 호출되는데, 이는 디폴트로 재 전송을 시도한다. 하위 클래스에서는 대응되는 메시지를 보여주거나 새로운 폼으로 리다이렉트 시켜 데이터 전송이 중복되는 것을 방지하기 위해 이 메소드를 재 저으이할 수 있다. 그 경우, 세션에 있는 폼 객체는 트랜잭션 토큰으로 생각될 수 있다.
뷰에서는 세션으로부터 폼 빈을 절대 추출해서는 안된다. 폼 컨트롤러에 의해 폼 빈이 마련될 때, 뷰는 항상 요청으로부터 폼 빈을 추출해야 한다. Velocity와 같은 몇몇 기술에서는 HTTP 세션에조차 접근할 수 없다는 사실을 명심하여라.
- referenceData(): 커맨드 객체 이외의 데이터가 필요할 때. showForm() 이 호출 될때 호출 된다.
- initBinder(): 바인터에 Custome property editor 등록하는데 사용.
- onBind(): 고유의 바인딩 방안을 적용하려고 할 때 사용. 자바 스크립트나 hidden 필드를 없앨 수 있다.
- onBindAndValidate(): Validator 없이 혹은 Validator로는 불가능한 validation을 수행하고자 할 때.
- ModelAndView onSubmit(), void doSubmitAction(): 데이터바인딩과 validation이 성공한 이후에 호출
- isFormChangeRequest(): 폼 제출 이전에 화면 변화가 필요한 경우. 가령, 국가를 선택한 이후에 관련 도시가 나타나는 폼을 처리하는 경우가 예가 된다.- formView, successView: 폼(form)을 포함하는 뷰와 폼 제출 및 처리 이후에 보여질 뷰의 이름. 더블 서밋 문제 해결을 위해서 successView 이름 앞에 redirect: 접두어를 붙이면, POST 이후에 연이어 GET 요청을 발생시켜서 form이 재전송 되는것을 방지해준다.
- sessionForm: 폼이 처음 보여질 때 새로운 객체를 생성할 것인지와 세션에 객체를 저장할지 여부를 결정. 커맨드 객체가 DB오퍼레이션을 요구하는 경우처럼 성능 이슈가 있는 경우는 true를 고려해봐야 한다. 디폴트는 false
bindOnNewForm: true로 설정하여 새로운 폼이 보여지는 시점에서 바인딩이 이뤄지게 할 수 있다. 디폴트는 false.validators: 데이터 바인딩 이후의 validation 작업을 수행할 객체 지정
validateOnBinding: 디폴트는 true이며, false 지정시 validation이 일어나지 않음
commandName: 디폴트인 command를 다른 이름으로 변경하고자 할 때
commandClass: 설정한 클래스의 인스턴스를 기본 form-backing 객체로 사용함. 부모 클래스의 formBackingObject() 구현에 의하면 디폴트 생성자로 commandClass 인스턴스를 생성한다.
