스프링 진영이 내놓았으니만큼 단순히 새로운 JSF 프레임워크는 아니었다. Spring Faces는 복잡함으로 명성(?)을 쌓아가고 있는 JSF를 보다 가볍게 하기 위해 등장했다. 이를 위해 Spring faces가 해결하려한 내용은
등이다. 한편, 스프링소스의 세션답게 본격적으로 Spring Faces를 다루기 전에 JSF 중심의 접근과 Spring 중심의 접근 차이에 대해 설명했다. JSF 중심 접근은 FacesServlet을 사용하는 방법으로 Spring을 JSF managed bean provider로 사용하는 방법이다. 반면에 스프링 중심의 접근은 FacesServlet을 쓰는 것이 아니라 Spring MVC와 Web Flow를 쓰면서 View 구현체로써 Spring Faces를 사용한다.
여기서 Spring Faces의 장단점이 확연히 보였다. 먼저 스프링 사용자라면 MVC/SWF는 물론 Spring 자바스크립트(주로 dojo 래핑)까지 그대로 사용할 수가 있다. 3.0 까지 고려하면 Spring MVC가 제공하는 RESTful URL을 사용할 수 있고, SWF의 flow 관리 기능을 그대로 사용할 수 있다. Spring JS를 쓰기 때문에 web.xml에 ResourceServlet 설정만으로 정적인 리소스는 보다 효율적으로 쓸 수 있다. 물론 이 기능은 Spring Faces를 쓰지 않아도 사용할 수 있다. Spring faces 고유의 설정은 FaceletViewHandler와 ViewRefreshmentListener 정도다. Keith Donarld가 SWF 발표를 할 때, 실수 연발했던 예제를 데모에 이용했지만 다행히 Jeremy Grelle의 데모는 원활했다. :)
장점만 이야기했는데 단점은 웹쪽에 대해서 즉, 스프링 MVC나 SWF 등을 쓰지 않는 경우에는 학습 비용을 들 수 있다. 발표자가 제공한 자료에서 Spring Faces를 사용했을 때 얻을 수 있는 이점을 잘 정리해서 보여줬다.
- JSF의 복잡한 XML 설정
- 성능 문제
- URL 매핑 제약
- Back 버튼 문제
등이다. 한편, 스프링소스의 세션답게 본격적으로 Spring Faces를 다루기 전에 JSF 중심의 접근과 Spring 중심의 접근 차이에 대해 설명했다. JSF 중심 접근은 FacesServlet을 사용하는 방법으로 Spring을 JSF managed bean provider로 사용하는 방법이다. 반면에 스프링 중심의 접근은 FacesServlet을 쓰는 것이 아니라 Spring MVC와 Web Flow를 쓰면서 View 구현체로써 Spring Faces를 사용한다.
여기서 Spring Faces의 장단점이 확연히 보였다. 먼저 스프링 사용자라면 MVC/SWF는 물론 Spring 자바스크립트(주로 dojo 래핑)까지 그대로 사용할 수가 있다. 3.0 까지 고려하면 Spring MVC가 제공하는 RESTful URL을 사용할 수 있고, SWF의 flow 관리 기능을 그대로 사용할 수 있다. Spring JS를 쓰기 때문에 web.xml에 ResourceServlet 설정만으로 정적인 리소스는 보다 효율적으로 쓸 수 있다. 물론 이 기능은 Spring Faces를 쓰지 않아도 사용할 수 있다. Spring faces 고유의 설정은 FaceletViewHandler와 ViewRefreshmentListener 정도다. Keith Donarld가 SWF 발표를 할 때, 실수 연발했던 예제를 데모에 이용했지만 다행히 Jeremy Grelle의 데모는 원활했다. :)
장점만 이야기했는데 단점은 웹쪽에 대해서 즉, 스프링 MVC나 SWF 등을 쓰지 않는 경우에는 학습 비용을 들 수 있다. 발표자가 제공한 자료에서 Spring Faces를 사용했을 때 얻을 수 있는 이점을 잘 정리해서 보여줬다.
