Sitemesh와 Apache Tiles에 관한 질문.
고재도
종로 모임에 참가하고 있는 고재도입니다.
스프링과 관련이 없지만... 물어볼 곳이 없어서 이곳에 글을 남겨요.
혹시 타일즈나 사이트메쉬 두개다 사용해 보신분 계신가요?
http://tiles.apache.org/framework/tutorial/pattern.html
위의 글로 부터 Composite View vs. Decorator 의 차이점을 알 수 있었습니다.
타일즈의 글이다 보니..타일즈가 더 낳은 듯한? 느낌을 받았는데요.
실무에선 어떠한지 확인할 길이 없어서.. 이렇게 글을 올립니다.
실무에서 무엇이 더 많이 씌의고 어떠한 장단점들이 있을까요?
Sewon Ann
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
Sungchul Park
사실 둘 다 마음에 안 듭니다.
제가 자주 하는 말로 "타일즈는 너무 가깝고 사이트메시는 너무 멀다"라고 할 수 있습니다.
일일히 페이지를 등록해줘야 하는 타일즈는 귀찮기도 하고 너무 정적입니다. 반면에 필터로 처리하는 사이트메시는 너무 간접적이고 성능과 관련된 걱정이 듭니다.
그래서 전 스프링의 TilesView를 확장해서 몇가지 템플릿 layout만 xml로 설정하고 특정 view의 layout은 동적으로 몇가지 룰에 따라 선택하도록 하는 방식을 사용했습니다.
아마 검색하시면 비슷한 방식으로 처리한 소스 코드를 구하실 수 있을 겁니다.
tiles는 2004~5년에 써 봤고 (struts1 시절), sitemesh는 2009년 정도부터 썼습니다. 그냥 간단한 느낌은, 링크 해 주신 페이지에도 얼추 나와있는 것 같긴 한데
1. tiles는 조그만 페이지들을 붙여 큰 페이지를 구성하는 느낌.2. sitemesh 는 페이지를 하나 가지고 겉에 포장을 씌우는 느낌
입니다. 참 애매한 표현이네요 ^^;
관리 페이지와 같이 조그만 페이지들을 모아서 화면을 구성할 땐 ( ex. 좌측 메뉴, 상단에 gnb, .. ) tiles가 좋았고,사용자 페이지와 같이 일관된 view를 보여줄 땐 sitemesh가 더 좋았던 듯 한데, 사실 tiles가 얘기하듯이 저렇게 조밀조밀하게 구성할 일이 그닥 많지 않고 되려 귀찮기만 하더라구요. 그래서 sitemesh로 구성했을 때가 더 관리는 편했던 듯 싶습니다.
다만 sitemesh로 할 땐 head, body 등 내부 페이지의 요소를 위의 decorator에서 갖다 쓰기가 tiles보다 쉽지 않았던 듯 하고, 태그 실수하면 화면이 몽창 빠져버리는 등 나름 주의해야 할 부분들이 있더군요. 또한, filter로 등록해서 쓰는데 filter 적용 순서도 유의를 해야 합니다. 항상 마지막에 두는 게 안전하겠지요.
상황따라 다르겠지만, 전 sitemesh에 한표를 던집니다.
2011/4/4 고재도 <haib...@gmail.com>
안녕하세요.
종로 모임에 참가하고 있는 고재도입니다.
스프링과 관련이 없지만... 물어볼 곳이 없어서 이곳에 글을 남겨요.
혹시 타일즈나 사이트메쉬 두개다 사용해 보신분 계신가요?
http://tiles.apache.org/framework/tutorial/pattern.html
위의 글로 부터 Composite View vs. Decorator 의 차이점을 알 수 있었습니다.
타일즈의 글이다 보니..타일즈가 더 낳은 듯한? 느낌을 받았는데요.
실무에선 어떠한지 확인할 길이 없어서.. 이렇게 글을 올립니다.
실무에서 무엇이 더 많이 씌의고 어떠한 장단점들이 있을까요?
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.
고재도
http://www.springbyexample.org/examples/dynamic-tiles-spring-mvc-module.html
을 참고하시면 좋을것 같아요.
하루정도 조사해보고 찾아서 내린결론은 "Tiles2를 잘 사용할 줄 알자" 입니다.
아무래도 sitemesh는 성능상 문제가 있는 것 같습니다.
좋은 답변 감사드립니다.
> > 2011/4/4 고재도 <haiban...@gmail.com <mailto:haiban...@gmail.com>>
>
> > 안녕하세요.
>
> > 종로 모임에 참가하고 있는 고재도입니다.
>
> > 스프링과 관련이 없지만... 물어볼 곳이 없어서 이곳에 글을 남겨요.
>
> > 혹시 타일즈나 사이트메쉬 두개다 사용해 보신분 계신가요?
>
> > http://tiles.apache.org/framework/tutorial/pattern.html
>
> > 위의 글로 부터 Composite View vs. Decorator 의 차이점을 알 수 있었
> > 습니다.
>
> > 타일즈의 글이다 보니..타일즈가 더 낳은 듯한? 느낌을 받았는데요.
>
> > 실무에선 어떠한지 확인할 길이 없어서.. 이렇게 글을 올립니다.
>
> > 실무에서 무엇이 더 많이 씌의고 어떠한 장단점들이 있을까요?
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메
> > 일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com
> > <mailto:ks...@googlegroups.com>(으) 로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com
> > <mailto:ksug%2Bunsu...@googlegroups.com>로 이메일을 보내주세요.
"손권남(KwonNam Son)"
를 해결 할 수 있습니다.
하지만 레아아웃 위에 레이아웃을 씌우는등 복잡하게 가기 시작하면 성능 저
하가 심하게 발생합니다.
성능 저하의 원인은 제가 보기엔 HTML을 파싱하기 때문인 것 같습니다.
HTML을 파싱해서 어디가 title,head,body 로 분리하고 그것을 레이아웃에 지
정된 title, head, body로 붙여넣는 방식으로 보입니다.
단순한 레이아웃 구성이라면 Sitemesh의 생산성이 매우 높으므로 추천합니다
만, 레이아웃이 계속해서 미묘하게 변화한다면 tiles 2를 쓰는게 더 좋아보입
니다.
2011년 04월 05일 11:17, 고재도 쓴 글:
파란하늘
저같은 경우 개인적으로 spring 3.0의 @mvc + tiles를 사용하여 사이트 구성을 해보았습니다.
viewResolver는 ContentNegotiatingViewResolver를 사용하였는데
의도한 것은
동일한 contents-type 인 text/html에 대해서
일반적인 주소(확장자 없는 경우) 호출의 경우 tiles의 template을 포함한 페이지 호출
.f 확장자 호출의 경우 template이 없는 바로 해당 페이지를 호출
위와 같은 처리를 하고자 하였습니다.
이유는 같은 페이지가 어떤 페이지에 import가 될 수도 있고, 혹은 독립으로 사용할 수도 있는데
동일 메소드 호출에 대해 controller에 여러 호출경로에 대해( 그냥 호출 메소드 ,.f 확장자 붙은 경우 호출 메소드)
매번 선언하는 것보다
확장자로 분기하지만 동일 controller method를 사용 후 viewResolver 에서 분기하는 것이
controller를 지저분하게 사용하지 않는 방법이라고 생각하였기 때문입니다.
문제는 ContentNegotiatingViewResolver의 Content-type이 동일한 타입에 대한 결정 설정을 하지
못한다는 점이었습니다.
만약 contents-type을 default( 확장자 없는 경우, text/html)와 .f확장자의 경우 text/html
로 설정하게 되면
단순히 ContentsNegitiatingViewResolver에서는 for문을 돌면서 제일 먼저 text/html 선언이 된
default의 경우로만 리턴을 해버립니다.
결국 ContentsNegotiatingViewResolver를 재구성하여 확장자 중복 선언 처리를 추가하여 해결을 하였지만
현재 스프링 3.0.5까지의 contentNegotiationgViewResolver는 contents-type에 대한 순위 설
정을 할수 없다는 단점이 있습니다.
(viewResolver 의 order 속성으로 해결할 수 있는 부분도 아니구요. viewResolver순위가 아닌
content-type순위 설정이 필요할 것 같습니다.)
개발하시면서 참고가 되실지 모르겠네요.
좋은 하루 되세요. (__)
On 4월6일, 오후1시43분, "손권남(KwonNam Son)" <kwon3...@gmail.com> wrote:
> Sitemesh는 단순 레이아웃에서는 거의 관리도 필요없고 굉장히 간편하게 문제
> 를 해결 할 수 있습니다.
>
> 하지만 레아아웃 위에 레이아웃을 씌우는등 복잡하게 가기 시작하면 성능 저
> 하가 심하게 발생합니다.
>
> 성능 저하의 원인은 제가 보기엔 HTML을 파싱하기 때문인 것 같습니다.
>
> HTML을 파싱해서 어디가 title,head,body 로 분리하고 그것을 레이아웃에 지
> 정된 title, head, body로 붙여넣는 방식으로 보입니다.
>
> 단순한 레이아웃 구성이라면 Sitemesh의 생산성이 매우 높으므로 추천합니다
> 만, 레이아웃이 계속해서 미묘하게 변화한다면 tiles 2를 쓰는게 더 좋아보입
> 니다.
>
> 2011년 04월 05일 11:17, 고재도 쓴 글:
>
>
>
> > 찾다 보니깐 Dynamic Tiles 2 Spring MVC Module이란 것도 있더군요.
>
> >http://www.springbyexample.org/examples/dynamic-tiles-spring-mvc-modu...
> >>> 룹을 방문하세요.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -