거미줄 치는 프로그래머

왜 그런가 했더니

초간단 설정문제였다. -_-

프로젝트 생성시에

Set Source Level to 1.4 라고 되어있는 check box에

체크를 해제시키고 생성시켜야한다.

이미 만들어진 프로젝트라면

프로젝트 속성(Properties)에 들어가서

Source Level을 1.4에서 1.5로 맞춰주면 해결된다.

Struts 프레임웍은 일반적으로 에플리케이션에서 필요한 각 입력폼당 하나의 ActionForm빈(이는 ActionForm을 상속하는 Java클래스임.) 하나를 정의한다고 가정합니다. ActionForm빈들은 때때로 "form beans"라고 불립니다. 만일 ActionMapping 설정 파일(Contoller 컴포넌트 만들기 참고)에 이같은 빈들을 선언하면, Struts 컨트롤러 서블릿은 적절한 Action메소드를 호출하기 전에 자동적으로 다음의 서비스들을 수행합니다.

• 적절한 키, 적절한 클래스의 빈 인스턴스가 사용자의 session에 있는지 체크합니다.
• 만일 이 같은 session scope 빈 인스턴스가 없다면, 자동으로 생성하고 이를 사용자의 session에 추가합니다.
• 이 빈의 속성들에 대응하는 파라미터에 대해, 대응되는 setter메소드를 호출합니다. 이 동작들은 어떤 의미로는 모든 속성들을 선택하기 위해 * 와일드카드를 사용하는 표준 JSP action <jsp:setProperty> 와 비슷합니다.
• 갱신된 ActionForm빈은 Action 클래스의 perform() 메소드에게 전달되고, perform() 메소드에 의해 호출되고, 사용 가능한 값들을 만들게 됩니다.

ActionForm빈들을 코딩할때, 다음의 원칙들을 명심해서 따르도록 합니다.

• ActionForm 클래스 자체는 어떤 특정한 메소드를 구현하는 것을 요구하지 않습니다. 그것은 전체 아키텍쳐에서 각각의 빈들이 수행하는 역할을 명시하기 위해 사용됩니다. 전형적으로, ActionForm 빈은 비지니스 로직없이 속성의 getter, setter 메소드만을 가집니다.
• 또한 ActionForm 오브젝트는 표준적인 검증 메커니즘을 제공합니다. "stub" 메소드를 오버라이드 하고, 에플리케이션 리소스에 에러 메시지를 추가하면, Struts는 자동으로 form의 input을 (오버라이드한 메소드로) 검증합니다. 자세한 것은 "Action Form 검증"을 참고하시길 바랍니다. 물론 ActionForm 검증을 사용하지 않고 Action 오브젝트 내에 고유한 검증 방법을 추가할 수도 있습니다.
• form에 있는 각 input 필드에 대한 속성을 정의합니다.(관련된 getXxx()와 setXxx()메소드들과 함께) form 필드 이름과 속성의 이름은 항상 JavaBeans 규약에 따라 반드시 매칭되어야 합니다. 예를 들어 username이라는 이름의 input 필드는 setUsername() 메소드를 호출하게 될 것 입니다.
• ActionForm 빈을 HTTP와 Action사이의 firewall이라고 생각야합니다. 요구되는 모든 속성의 상태와 적합한 값임을 확인하기 위해 validate 메소드를 사용합니다. 검증에 실패한 ActionForm은 Action에서 처리 되지 않을 것 입니다.
• form에 빈 인스턴스(bean instance)를 놓을 수도 있고, 중첩된 속성 레퍼런스도 사용할 수 있습니다. 예를 들어, Action Form상에서 "customer" 빈을 가진다면, JSP view에서 "customer.name" 속성을 참조할 수 있습니다. 이는 customer빈의 customer.getName()와 customer.setName(String name)에 대응합니다. 중첩된 문법에 대한 보다 자세한 내용은 Tag 라이브러리 개발자 가이드를 보시기 바랍니다.
• 주의: 만일 존재하는 빈 인스턴스(bean instance)를 form 상에 입력한다면, 인스턴스의 속성을 생각해야 합니다. ActionForm 상의 모든 public 속성들은 form 내부에서 하나의 String값으로 설정될 수 있습니다. 요구되는 속성만을 드러내는 가벼운 "wrapper"를 빈에 추가하는 것이 좋을 것 입니다. 또한 wrapper는 런타임에 적합하지 않은 속성이 설정되지 않음을 보장하는 필터를 제공할 수도 있습니다.

여기서 논의하고 있는 "form"은 반드시 유저 인터페이스 내에 하나의 JSP페이지에 대응되는 것은 아닙니다. 많은 애플리케이션에서 여러 개의 페이지에 확장된 (유저의 관점에서) 하나의 "form"을 가지는 것은 일반적인 일입니다. 예를 든다면, 보통 새로운 에플리케이션을 인스톨할때 사용되는 마법사 스타일의 유저 인터페이스를 생각해보시기 바랍니다. Struts는 (form의)필드가 어떤 페이지에서 보여진다 할지라도 모든 필드에 대한 속성을 포함하는 하나의 ActionForm빈을 정의할 수 있습니다. 따라서, (편주:같은 ActionForm이라면) 다양한 페이지의 같은 form은 같은 Action 클래스로 submit될 것이다. 만일 이런 제안을 따른다면, 페이지 디자이너는 페이지의 처리 로직을 자주 바꿀 필요없이 다양한 페이지 사이에서 (form)필드들을 재배치할 수 있습니다.