WebWork에 대해

WebWork의 특징

액션 매핑

xwork.xml 에 액션명과 대응하는 클래스를 명시하면 클래스 안에서 액션명과 일치하는 메소드를 실행시켜줌

뷰 선택

액션이 실행되고 난 후 JSP, FreeMarker 등의 뷰를 선택할수 있다.

손쉬운 파라미터 처리(Value Stack)

액션 클래스에 setter와 getter를 설정하면 메소드명과 일치하는 메소드를 호출해 값을 자동으로 셋팅해 준다.
- 뷰에서 ${user} 이라고 적으면 액션의 getUser() 호출

파라미터가 객체인경우에 그 객체의 메소드도 접근가능
- 뷰에서 ${user.name}이라고 사용하면 액션의 getUser().getName()을 호출하게 됨

params라는 기본적인 Intercepter 필요 

Thread Local

액션 수행과정을 스레드로 수행을 하는데, 그 과정에서 리퀘스트 정보를 글로벌하게 접근하기 위해서 리퀘스트의 파라미터등 정보를 가지고있는ActionContext를 스레드 로컬로 사용을 한다.

스트러츠와의 비교
- 둘다 스레드로 액션이 실행되는데 스트러츠의 경우는 같은 액션에 대해 멤버 필드가 공유되어 값의 안정성을 확신할수 없다.
- WebWork의 경우는 Thread Local을 사용하여 스레드 마다 별도의 메모리가 할당되어 같은 액션이라도 리퀘스트마다 별도로 실행된다.

Archetecture

그림출처 : http://www.opensymphony.com/webwork/wikidocs/Architecture.html

Archetect 페이지 번역

- 최초로 request는  Servlet container(Tomcat or Resin)로 들어오고, 그  Request는 standard filter chain을 통과한다. 만약, SiteMesh같은걸 추가한다면 옵션으로 ActionContextCleanUp을 추가할 수도 있지만, 최초로 호출되는 건 FilterDispatcher이다. (역자주 : FilterDispatcher는 web.xml에 설정되어 있다.)

- FilterDispatcher는 ActionMapper를 이용하여 request URL에 매핑될 Action클래스를 찾는다.(xwork.xml 참조)

- 이렇게 Action클래스를 찾으면, ActionProxy에 모든 작업을 위임한다.

- ActionProxy는 ActionInvocation을 생성한다.

- 적용할 Interceptor가 있다면, Action 전,후로 Interceptor가 차례대로 실행된다.

- Action이 실행된 다음 결과값(result)을 얻는다.

- result에 해당하는 데이터를 xwork.xml로부터 찾아와 해당 페이지(jsp or siteMesh or Tiles..)로 이동하게 된다.

Action Mapper와 ActionProxy의 차이

- 둘다 FilterDispatcher에 의해 관리 됨

- xwork.xml을 참조해 정보를 가져옴

- Action Mapper : xwork.xml에서 해당 액션에 맞는 클래스정보를 가져온다.

- Action Proxy : xwork.xml을 참조해 intercepter 및 수행할 액션, 결과페이지 렌더링까지 수행한다. => ActionInvocation생성  

수행 흐름 정리

- Request요청 -> Servlet Contatiner(Tomcat,etc) -> web.xml -(filter)-> FilterDispatcher -> ActionMapper(xwork.xml) -(FilterDispatcher)->ActionProxy

- ActionProxy 그림

환경설정 파일들

필수
- web.xml : 웹워크에 필요한 필수사항을 정의한 DD파일
- xwork.xml : 메인 설정, result,view타입, 액션 매핑, interceptor등등정의

선택
- webwork.properties : webwork의 properties
- webwork-default.xml : xwork.xml의 기본설정이 담길수 있음

[출처]WebWork|작성자마루아라