근데 지금 댓글 쓰면서 생각해 보니까,
그럴 상황이 올 가능성이 있는지는 모르겠지만
만에하나 나중에 Tomcat으로는 도저히 안되고 다른 서버를 써야할
상황이 온다해도 서버 바꾸면 되는거네요…ㅡ_ㅡ;;;
Hibernate를 쓰면 다른 서버에서 안 돌아가는것도 아니고…

JTA 문제는 제가 참 바보 같은 고민을 해서
Toby의 시간을 뺏었네요. 죄송합니다…^^;;;

어쨌든 추천 정말 고맙습니다. 나중에라도 요긴하게 쓸때가 있을것 같네요.

특별히 표준을 써야 한다는 명분은 없구요.
사실 저도 J2EE 표준의 희생자라고 생각합니다…^^;
아무튼 OpenSource 이기만 하면 아무 상관없구요.

단지 마음에 걸리는게 Gavin King이 쓴 책에서
Tomcat에는 transaction manager가 딸려오지 않기 때문에
JTA호환 transaction manager를 설치해야 할수도 있지만,
JBoss같은 JEE Server를 쓸경우 이런 걱정없이 설정도 쉽고
서비스도 더 좋다고 하던데요.
Tomcat에 Hibernate를 쓸 경우,
이건 걱정할 필요가 없을 정도 일까요?

Hibernate나 JPA 중에 하나를 고르려고 하고 있습니다만,
아, 물론 Spring하고 같이 쓰려구요.

죄송한 말씀이지만, 혹시 언제 시간이 되시면
간단하게라도 둘중에 어떤쪽을 어떤이유로 추천하신다거나

혹은 간략하게 장단점 및 차이점 비교 같은거라도
해주실수 없을까요?

바쁘실테니 자세히는 바라지 않고, 간단하게 이러이러 해서
이쪽이 Spring하고 쓰기 좋다거나
이러이러해서 향후 전망이 불투명하니 이쪽을 쓰라거나…

Gavin King이 JPA 개발에 참여하면서 둘이 비슷해진건
알겠는데 자세한건 아무래도 자주 사용해 보신 전문가분께서
잘 아실테니까요.

Web Application 용이고, 서버는 Tomcat 6를 쓸 예정입니다.
바쁘셔서 곤란하시면 이 질문은 그냥 모른척 하셔도 돕니다…^^;
바쁜상황에서는 정말 1분 1초가 중요하다는걸 잘 알고 있어서
충분히 이해할수 있고, 답변하실 의무가 있는것도 아니구요.
그럼, 좋은밤 되세요.

표준이 있는게 문제가 아니라 브라우저들이 잘 지키지 못해서 그런게 아닐까요?
이건 Java쪽 J2EE표준이 삽질한 것하고는 경우가 다른거 같은데요.
Java는 그 몹쓸 J2EE 표준을 안 지켜도 결국 Java라는 틀안에서 만드는거라서
크게 문제될 일이 없… 는 정도가 아니라 개발자나 고객 모두 이익을 보지만,

브라우저 쪽은 전혀 다른 얘기가 되겠죠…ㅡ_ㅡ;
브라우저마다 개판으로 보이는게 표준이 있어서 그런게 아니라
표준을 안 지켜서 그런거 아닌가요?

표준이 없다고 가정을 해보면,

브라우저 별로 천차만별 다 다르게 보임 => 해결하려면, 브라우저 별로 View를 개별적으로 생성

그럼 표준이 있으면 개별적으로 만들수 없는건가요?
아니죠. 개별적으로 만들수 있죠. 근데 더 좋은건 브라우저들이
표준을 지켜서 한쪽에서 돌아가면 다른곳에서도 잘 돌아가는
웹페이지 생성이 가능한게 좋겠죠.

결국 표준과는 상관없는 얘깁니다. IE에서만 보이게 만들건
FF에서만 보이게 만들건 그건 표준이 있건 없건 가능한 얘기구요.

표준이 있고, 브라우저들이 이걸 지키면, 개발자는 표준만 따르면
Cross Browsing이니 하는건 신경 안 써도 되겠죠.
고객들도 원하는 브라우저를 쓰면서 제대로된 화면을 보니 좋겠구요.

결국 시초는 과거에 그넘에 M$가 독점하려고 지들 멋대로 나가면서…
M$가 얼마나 삽질하고 있는지는 이걸…ㅡ_ㅡ;
en.wikipedia.org/wiki/Acid3
IE쪽 결과물의 참담함을 한번 보세요.

아, 그리고 Toby님 혹시 이거 보셨나요?
http://www.mozilla.or.kr/docs/web-developer/web-standard-guide-2005-appendix.pdf

브라우저 마다 미묘한 차이야 어쩔수 없겠지만,
사실 고객도 그런 미묘한건 크게 신경 안 쓸거 같구요.
(로그인 버튼이 password field랑 1밀리 떨어졌건 2밀리 떨어졌건 고객이 불만 접수할 일은 없지 않을까요?ㅡ_ㅡ?)
암튼 저 문서 꽤 도움 되더군요.

말씀하신 WYSIWYG툴이 없는건 아닙니다만,
만들고 나서 브라우저 호환성까지 좋은거는 대부분 Ajax용이라서…
사실 개인적으로는 Accessibility 문제만 해결이 잘 된다면,
JavaScript Framework를 사용하는게 여러 모로 훨씬 이익인거 같습니다.
사이트도 이뻐지고, 특정부분은 속도도 빨라지고
무엇보다 Cross Browser문제는 Framework에서 신경 쓰기 때문에
개발자의 부담이 아주아주 줄어들죠.

전 Java와 Ajax로 웹어플 개발을 했는데요.
저는 Server-side Java이고, 같이 일하는 친구가 Ajax쪽을 맡았거든요.
JS UI library 안 쓰고 개인적으로 UI Library를 만들어 썼어요.

문제는, 뭐 하나 바뀔때마다 Browser별로 안 돌아가거나, 심지어 같은 브라우저도
버전업 되면서 안 돌아가고…ㅡ_ㅡ; UI library 안 쓴걸 정말 후회 했었죠.
사실 이친구는 쓰려고 했는데, 프로젝트 중간에 조인한 거라서
이미 전임자가 UI library 안 쓰고 개발한 상태라서, 다 갈아엎을수도 없고…

그래도 결국 FF2+, IE7, Opera 9.5+, Safari3+, Google Chrome에서
돌아갈수 있게 만들었는데, 만드는 동안 짜증나는건 좀 많았죠…

특히 문제가, 다른 브라우저들 다 정상인데, IE만 꼭 말썽을…ㅡ_ㅡ;

아…
그리고 혹시 Rich Ajax Platform (RAP) 아시나요?
간단하게 설명하면,
SWT를 써서 Java로 만들어진 UI를 JS library인 qooxdoo를 이용해서
브라우저쪽에서 렌더링해서 HMTL페이지로 만들어 주는건데,
SWT UI와 거의 1:1 대응을 해서
데스크톱 어플을 그대로 웹어플로 만드는 효과를 기대할수 있죠.

뭐 JS UI library쪽으로 눈을 돌리면 쓸만한게 꽤 많죠.
RAP에서 기본 JS 엔진으로 쓰는 qooxdoo말고도 ExtJS나 Ext GWT
그리고 Spring은 Dojo를 쓰던가요?

RAP와 Ext GWT는 이걸 보시면 좋을거 같구요.
http://www.eclipsecon.org/2008/sub/attachments/RAP_vs_GWT__Which_AJAX_Technology_is_for_You.pdf

아 근데… 이미 다 알고 계신 것들을 가지고, 저혼자 삽질하고 있는거 같기도 하고…ㅡ_ㅡ;;;
암튼, 계속 좋은글 써 주셨으면 하는 뜻으로 몇삽 떴습니다…ㅡ_ㅡ;;;

CodeIgniter 참 좋죠. CakePHP나 젠드보다는 어딘지 모르게 빈약해 보이긴 하지만, 매우 유연하고 가볍습니다. 저도 한 반년 전부터 CI를 써오고 있어서 기쁜 마음에 답글 달아봅니다. ^^

얼치기 Java개발자인 나는 Java부분에서도 “차라리 표준이 없었더라면..” 하는 생각을 할때가 많아. ㅋㅋ

PHP는 그런면에서 고맙지..

여튼 화이튕이야~

대부분의 진통은 브라우저가 CSS를 해석하는 방식의 차이에서 발생합니다. HTML은 사이트가 화면에서 어떻게 보이느냐랑은 관계가 없거든요.