Framework - Validation

자비를 7년정도 SQL을 다룬지는 10년이 넘었지만 그럼에도 개인적으로 가장 자신있는 언어가 무엇이냐고 묻는다면 아마도 Javascript라고 말하지 않을까 싶다. XP의 김창준씨는 개발자는 1년에 최소한 한개의 언어를 익히는게 좋다라고 하는데 굳이 익히려 노력하지는 않았지만 그 동안 다룬 언어는 Pascal부터 시작해서 C, VB, C#, Java등이 있고 사용한 Web Script 언어는 ASP나 PHP, Perl 등등 어쩌다 보니 여러가지 언어를 해보게 되었다. 그리고 그 어떤 언어보다 Javascript의 간결함과 우아함을 좋아한다.

프로그래머는 태생적으로 간결함의 미학을 좋아하는 것 같다. 다만 그 간결함을 파이썬이나 루비 등에서 찾곤 하는데 - 예전에는 자바도 그런 미학이 있었는데 최근의 자바는 너무 살이 쪘다. - 개인적으로는 Java하고 비슷한 문법이라 그런지 모르겠지만 Javascript가 더 재미있다.


보통의 초보 프로그래머들이 작성하는 Form Validation 코드는
var frm = document.forms[0] ;
if (frm.subject.value == '')  {
    alert ('글 제목이 비었음') ;
    frm.subject.focus() ;
} else if (form.subject.value.length > 200 ) {
    alert('글제목은 200자까지 가능') ;
    frm.subject.focus() ;
} else if (..... )
   ,,,,,,

}
frm.submit() ;
... 런식인데 위 코드는 몇가지 문제를 가지고 있다.

첫번째 복잡하다. 앞의 글에서 복잡하다와 어렵다는 다르다고 말한적이 있는데 위 식으로 작성된 코드는 매우 쉽지만 아주 아주 복잡한 코드가 된다. 복잡한 이유는 대부분의 경우 중복이 많기 때문이다. 중복이라는 것은 단순히 코드의 중복만을 말하는 것은 아니다. 실제의 프로그램에서는 위와 거의 동일한 수십개의 코드를 작성해야 겠지만 위 코드만을 본다면 코드 자체만으로는 중복이 되지 않았다. 다만 구조적인 중복이 있다. 위 코드는 하나의 if 절이 모두
 1) if 조건 확인
 2) 조건이 달성되지 않았을때 어떤 액션을 함
      alert 창을 띄움
      focus를 맞춤
이라는 구조적인 중복이 있다. 코드의 중복은 라이브러리로 해결이 가능하지만 - 이를테면 getLength(formElementName) 같은 함수로 해결할 수 있겠지만 - 구조적인 중복은 대부분 프레임워크로 해결이 되어야 한다.

두번째로 위 코드는 활용적인 면에서도 그닥 실용적 - 요즘에는 실용이라는 말에 거부감이 생기지만 -ㅅ- 이지 않다. 예컨데 i18n의 다국어 메시지 처리도 곤란하고 다른 라이브러리나 프레임워크와도 호환이 좋지 않다.

form_valid.js

그래서 꽤 오래전에 작성한 코드지만 위와 같이 js를 만들어서

  fvalid.setForward('add') ;
  fvalid.required("subject", "<%= m.get("jmsg.validate_null", m.get("etc.subject") ) %>", true);
  fvalid.maxLengthByte("subject", 200, "<%= m.get("jmsg.length", m.get("etc.subject"), "1", "200") %>", true);
  fvalid.notAllowed2ByteSpace("subject", "<%= m.get("jmsg.include_fullwidth_space", m.get("etc.subject") ) %>", true);
  fvalid.required("content", "<%= m.get("jmsg.validate_null", m.get("etc.cont")) %>", true);

런식으로 사용하는데 그 기본원리는 간단하다.

여러가지 효율상의 이유로 자바의 경우 쓰레드를 사용해서 invokation와 execution를 분리시키는데 위 코드는 declaration과 execution을 분리한 것이다. 이런 방식을 선언적 프로그래밍 이라고도 할 수 있는데 이렇게 해서 얻을 수 있는 장점은 구조적인 중복을 없엘수 있는것과 다른 코드와 꽤 접착이 잘된다는 점이다.

fvalid.required 메소드를 호출했을때 호출 당시에 바로 실행되어 subject의 유효성을 확인 하지 않는다. 다만 subject는 빈 내용이 되어서는 안된다는 정보가 객체 형태로 변환되어 어딘가에 저장될 뿐이다. 어찌보면 execution을 executable infomation으로 바꾼다는 점에서는 command 패턴과 유사하게 보일 수도 있지만 목적이 다르다.

이렇게 선언이 되면 실제 유효성의 실행은 fvalid.isValid() 함수를 호출함으로써 이루어진다.



어쨌거나....Javascript 얘기를 하려던건 아니고..  이 글의 본래 주제는 Java에서는 Validation을 어떻게 처리해야 하는가이다. 찾아보면 그 쓰임의 양에 비해서 의외로 쓸만한 코드가 거의 없다. Spring 모듈에 포함되어 있는 Validation이 그나마 가장 많이 알려지긴 했지만 이는 몇가지 문제가 있다.

Spring에서 Validation을 할수 있는 방법은 크게 2가지인데 하나는 자바 코드에 직접 사용하는 Case1) Programmatic 방법이고 다른 하나는 XML 설정파일을 이용하는 Case2) Declarative 방법이다.

Case1 ) 
    public void validate(Object object, Errors errors) {
        ValidationUtils.rejectIfEmptyOrWhitespace(errors, "email", "required", "Enter your email");
        ValidationUtils.rejectIfEmptyOrWhitespace(errors, "password", "required", "Enter your password");
        ValidationUtils.rejectIfEmptyOrWhitespace(errors, "confirmPassword", "required", "Enter the same password for confirmation");
        ValidationUtils.rejectIfEmptyOrWhitespace(errors, "confirmMember", "required", "Enter ajn member code");
        ValidationUtils.rejectIfEmptyOrWhitespace(errors, "name", "required", "Enter your name");
    }


Case 2)
<bean id="caseSwappingValidator" class="org.springmodules.validation.ValangValidatorFactoryBean">
 <property name="syntax">
  <value>    <![CDATA[ { name : alterCase(?) = 'sTEVEN' : 'Name must be Steven' }  ]]>  </value>
       </property>

 <property name="customFunctions">
     <map>
         <entry key="alterCase" value="com.apress.expertspringmvc.validation.AlterCaseFunction" />
  </map>
 </property>
</bean>


근데 2가지 방법 모두 별로다 -ㅅ-;

첫째로 앞의 다른 글에서 언급한적이 있지만 Validation 정보는 대부분 구성 정보에 가깝기 때문에 자바 코드에서 직접 확인하는 것은 바보같은 짓이다. 

두번째로 그래서 Bean의 XML 설정을 하기도 하는데 게시판 하나 달랑 있는 프로그램이라면 모르겠지만 그 양이 만만찮아서 XML 파일을 작성하기가 쉽지 않을뿐더러 그 대다수가 중복 정보이다. 실수로 오타라도 있다면 실제 에러가 발생하기 전까지는 거의 확인이 어렵다.

세번째로 Spring에 너무 긴밀히 통합이 되어 있어서 접착성이 많이 떨어진다. 더군다나 이 모듈을 활용하려면 HTML 작성시 id attribute 등의 일정한 약속을 따라야 한다. 

첫째 문제는 언급할 필요도 없고 사실 가장 큰 문제는 2번째인 지나친 XML 파일의 비대화이다. Framework가 유행을 타면서 원칙대로 구성정보를 설정할 수 있도록 XML 파일을 많이 활용하긴 하지만 지나친 욕심으로 일반화를 너무 많이 추구한 나머지 상대적으로 너무 많은 정보를 구성 정보에 적어야 작동할 수 있게 되어 버렸다. 

대규모 재사용은 소규모 재사용과 그 의미가 많이 다르다라고 이전에 말한적이 있는데 어느 규모이상의 코드에서 재사용의 활용도를 높이면 높일수록 이런 반작용이 더욱 심해진다. 즉 이것은 Spring Framework 개발자의 잘못은 아니지만 SpringFramework의 덩치가 커져서 더 일반화를 가지려고 할수록 실제 활용도는 오히려 떨어진다는 말이다.


그래서 좀더 간결한 방법을 찾을 필요가 있다.


다음에 계속....