가장 큰 GWT 함정?[닫은]
https://stackoverflow.com/questions/99866
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
저는 GWT를 사용하여 구현하기로 선택한 프로젝트의 시작/중간에 있습니다.GWT(및 GWT-EXT)를 사용할 때 극복할 수 없는 주요 함정에 직면한 사람이 있습니까?성능 측면에서는 어떻습니까?
우리가 이미 보거나 들었던 몇 가지 사항은 다음과 같습니다.
- Google이 콘텐츠의 색인을 생성할 수 없습니다.
- 일반적으로 CSS와 스타일이 약간 불안정한 것 같습니다.
이러한 항목에 대한 추가 피드백도 찾고 있습니다.감사해요!
해결책
나는 엄청난 GWT 팬이라는 점부터 시작하겠습니다. 물론 많은 함정이 있지만 우리가 극복할 수 있었던 전부는 아니더라도 대부분은 다음과 같습니다.
문제: 긴 컴파일 시간, 프로젝트가 성장함에 따라 컴파일하는 데 걸리는 시간도 늘어납니다.컴파일 시간이 20분이라는 보고를 들은 적이 있는데, 제 경우는 평균 1분 정도입니다.
해결책: 코드를 별도의 모듈로 나누고 개미에게 변경된 경우에만 빌드하도록 지시하십시오.또한 개발하는 동안 하나의 브라우저에 대해서만 빌드하여 컴파일 시간을 크게 단축할 수 있습니다.이를 .gwt.xml 파일에 넣으면 됩니다:
<set-property name="user.agent" value="gecko1_8" />
여기서 gecko1_8은 Firefox 2+이고, ie6은 IE 등입니다.
문제: 호스트 모드는 매우 느리며(적어도 OS X에서는) JSP 또는 Rails 페이지와 같은 항목을 편집하고 브라우저에서 새로 고침을 누를 때 얻는 '실시간' 변경 사항과 거의 일치하지 않습니다.
해결책: 호스트 모드에 더 많은 메모리를 제공할 수 있지만(일반적으로 512M에 해당) 여전히 느립니다. GWT를 충분히 사용하면 이 사용을 중단한다는 것을 알았습니다.많은 부분을 변경한 다음 하나의 브라우저에 대해 컴파일한 다음(일반적으로 20초 분량의 컴파일) 브라우저에서 새로 고침을 누르기만 하면 됩니다.
업데이트:GWT 2.0+에서는 새로운 '개발 모드'를 사용하므로 더 이상 문제가 되지 않습니다.이는 기본적으로 선택한 브라우저에서 코드를 직접 실행할 수 있으므로 속도 저하가 없으며 방화범/검사 등을 수행할 수 있음을 의미합니다.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
문제: GWT 코드는 Java이며 HTML 페이지 레이아웃과 사고 방식이 다르기 때문에 HTML 디자인을 가져와 GWT로 전환하는 것이 더 어렵습니다.
해결책: 다시 익숙해지겠지만, 불행하게도 HTML 디자인을 GWT 디자인으로 변환하는 것은 HTML 디자인을 JSP 페이지로 변환하는 것과 같은 작업을 수행하는 것보다 항상 느립니다.
문제: GWT는 머리를 숙이는 데 약간의 시간이 걸리며 아직 주류가 아닙니다.이는 팀에 합류하거나 코드를 유지 관리하는 대부분의 개발자가 처음부터 코드를 배워야 함을 의미합니다.
해결책: GWT가 도약할지는 두고 봐야 알겠지만, 회사가 채용할 사람을 통제한다면 언제든지 GWT를 알고 있거나 배우고 싶어하는 사람을 선택할 수 있습니다.
문제: GWT는 jquery나 일반 자바스크립트와 비교하면 큰 망치입니다.JS 파일을 포함하는 것보다 이를 수행하려면 훨씬 더 많은 설정이 필요합니다.
해결책: 이에 적합한 더 작고 간단한 작업에는 jquery와 같은 라이브러리를 사용하세요.AJAX에서 매우 복잡한 것을 구축하려는 경우 또는 RPC 메커니즘을 통해 데이터를 앞뒤로 전달해야 하는 경우 GWT를 사용하십시오.
문제: 때로는 GWT 페이지를 채우기 위해 페이지가 처음 로드될 때 서버를 호출해야 합니다.필요한 데이터를 가져오는 동안 사용자가 거기 앉아서 로딩 기호를 보는 것은 성가실 수 있습니다.
해결책: JSP 페이지의 경우 HTML이 되기 전에 페이지가 이미 서버에 의해 렌더링되었으므로 실제로 모든 GWT 호출을 수행하고 즉시 로드하기 위해 페이지에 미리 로드할 수 있습니다.자세한 내용은 여기를 참조하세요.
GWT 호출을 사전 직렬화하여 페이지 로딩 속도를 높입니다.
저는 CSS로 내 위젯을 즉시 스타일링하거나 사용자 정의하거나 다른 방식으로 스타일링하는 데 문제가 없었는데 그게 함정이라는 것이 무슨 뜻인지 모르겠습니다.
성능에 관해서는 일단 컴파일된 GWT 코드가 빠르며 AJAX 호출이 전체 페이지 새로 고침을 수행하는 것보다 거의 항상 작다는 것을 알았습니다. 그러나 이는 실제로 GWT에 고유한 것은 아닙니다. JAVA 백엔드는 매우 컴팩트합니다.
다른 팁
우리는 거의 2년 동안 gwt와 협력해 왔습니다.우리는 많은 교훈을 얻었습니다.우리가 생각하는 것은 다음과 같습니다.
타사 위젯 라이브러리, 특히 gwt-ext를 사용하지 마세요.디버깅, 개발 및 런타임 성능이 저하됩니다.어떻게 이런 일이 일어나는지 궁금한 점이 있으면 저에게 직접 문의하세요.
앱의 동적 부분만 채우려면 gwt를 사용하세요.따라서 많은 필드와 복잡한 사용자 상호 작용이 있는 경우.그러나 함께 제공되는 패널을 사용하지 마십시오.기존 스톡 디자이너가 제공한 페이지를 가져가세요.앱 컨트롤이 포함될 영역을 개척하세요.onModuleLoad() 내의 페이지에 이러한 컨트롤을 연결합니다.이렇게 하면 디자이너의 표준 페이지를 사용할 수 있고 gwt 외부에서 모든 스타일링을 수행할 수도 있습니다.
전체 앱을 하나의 표준 페이지로 구축한 다음 모든 부분을 동적으로 구축하지 마세요.항목 2에서 제안한 대로 수행하면 어쨌든 이런 일이 발생하지 않습니다.모든 것을 동적으로 구축하면 중대형 앱의 경우 성능이 저하되고 엄청난 양의 메모리를 소비하게 됩니다.또한 내가 제안하는 대로 수행하면 뒤로 버튼이 잘 작동하고 검색 엔진 색인 생성 등도 잘 작동합니다.
다른 댓글 작성자도 좋은 제안을 했습니다.제가 사용하는 경험 법칙은 표준 웹 페이지를 만드는 것처럼 페이지를 만드는 것입니다.그런 다음 역동적이어야 하는 부분을 개척하세요.ID가 있는 요소로 교체한 다음 사용하세요. RootPanel.get( id ).add( widget ) 그 부분을 채우려고요.
우리가 직면한 함정:
GWT EXT와 같은 것을 사용하면 많은 마일리지를 얻을 수 있지만 JavaScript 라이브러리 위에 이런 종류의 얇은 베니어를 사용할 때마다 디버깅 기능을 잃게 됩니다.GWT EXT 테이블 클래스에서 무슨 일이 일어나고 있는지 (IntelliJ 디버거 내부에서) 검사할 수 없기 때문에 여러 번 책상에 머리를 세게 부딪혔습니다...당신이 볼 수 있는 것은 그것이 JavaScriptObject라는 것뿐입니다.이로 인해 무엇이 잘못되었는지 파악하기가 매우 어렵습니다.
팀에 CSS를 아는 사람이 없습니다.내 경험에 따르면 그 사람이 전문가가 아니더라도 상관이 없었습니다. 그 사람이 어느 정도 좋은 실무 지식을 갖고 있고 필요할 때 Google에 적합한 용어를 아는 것만으로도 충분합니다.
브라우저 전반에서 디버깅.Out of Process 호스팅 모드를 주의 깊게 살펴보세요[1][2][3], GWT 1.6에 나오길 바랍니다...지금은 호스트 모드를 사용하여 좋은 결과를 얻은 다음 "컴파일/찾아보기" 버튼을 사용하여 다른 브라우저에서 플레이할 수 있습니다.나에게 있어서 Windows에서 작업한다는 것은 FireFox에서 내 작업을 볼 수 있고 FireBug를 사용하여 작업을 조정하고 개선할 수 있다는 것을 의미합니다.
IE6.IE 6이 사물을 얼마나 다르게 렌더링하는지 놀랍습니다.나는 다음과 같은 CSS 규칙을 가질 수 있도록 브라우저에 따라 가장 바깥쪽 "뷰포트"에 스타일을 적용하는 접근 방식을 취했습니다.
.my-style { /* stuff that works most everywhere */ } .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
마지막으로, 도움이 되는 편집기를 사용하십시오.저는 IntelliJ를 사용합니다. 여기에는 많은 GWT 스마트 기능이 있습니다.예를 들어 JRE 에뮬레이션에서 처리되지 않는 클래스를 사용하려고 하면 알려줍니다.위젯에 대한 스타일을 지정하고 해당 스타일을 아직 정의하지 않은 경우 코드에 작은 빨간색 물결 모양이 표시됩니다.또는 CSS를 보면 단일 규칙에 충돌하는 속성을 지정했을 때 알려줍니다.(아직 시도하지는 않았지만 버전 8에는 "로컬" 및 "비동기" RPC 인터페이스와 구현을 동기화하는 등 훨씬 더 나은 GWT 지원이 포함되어 있다는 것을 알고 있습니다.)
앞으로 몇 달 안에 출시될 예정인 GWT 2.0은 논의된 많은 문제를 해결합니다.
- 구문과 같은 html/xml을 사용하여 레이아웃 만들기
- 동적 스크립트 로딩 - 처음에는 필수 JS만 다운로드됩니다.나머지는 필요에 따라 다운로드됩니다.
- 브라우저 내 호스팅 모드 - 이는 논의된 호스팅 모드 속도 문제와 다른 이점을 처리할 수 있습니다.
- "컴파일러 최적화" - 컴파일 속도가 빨라지길 바랍니다.
"극복할 수 없다"는 것이 아니라 기본적인 것에 대한 약간의 고통입니다.
날짜 처리:
GWT는 더 이상 사용되지 않는 java.util.Date 클라이언트 측에서 날짜를 처리할 때 예기치 않은 동작이 발생할 수 있습니다. java.util.Calendar GWT에서는 지원되지 않습니다. 자세한 내용은 여기를 참조하세요.
관련 문제 예:
이미 언급한 내용에 몇 가지 사항을 추가하겠습니다.
- 데이터 바인딩/검증.GWT에는 기본적으로 데이터 바인딩/검증 지원 기능이 없지만 이 영역에 대한 일부 프로젝트가 등장하기 시작했습니다.다음과 같은 글을 많이 쓰게 될 것입니다.
TextField fname, faddress; ... fname.setText(person.getName()); faddress.setText(person.getAddress()); ...
- 지연 로딩.gwt는 클라이언트 측에 있으므로 지연 로딩은 실제로 옵션이 아닙니다.RPC와 도메인 개체를 신중하게 디자인해야 합니다.
- 필요한 모든 개체 데이터를 보냅니다.
- 모든 데이터를 열심히 가져오는 것을 피하세요
- 또한 프록시/직렬화할 수 없는 개체를 보내지 않도록 해야 합니다. 최대 절전 모드4gwt 이러한 점에 대해 도움을 드릴 수 있습니다.
- UI 디자인.HTML보다 Java(패널, 버튼 등)에서 UI를 시각화하는 것이 더 어렵습니다.
- 역사 지원.GWT는 기록 하위 시스템과 함께 제공되지 않으며 멋진 URL 또는 상태 전체 북마크를 위한 하위 시스템도 함께 제공되지 않습니다.(처음에는 히스토리 토큰을 지원하지만) 직접 굴려야 합니다.이는 모든 AJAX 툴킷 AFAIK에서 발생합니다.
IMHO, GWT에는 이 '스레드'에 언급된 모든 문제를 즉시 지원하는 프레임워크가 없습니다.
저는 지금 GWT EXT와 혼동하지 않도록 EXT GWT(GXT)를 사용하는 프로젝트를 진행하고 있습니다.차이점이 있는데, EXT GWT는 실제로 자바스크립트 라이브러리인 ExtJS를 작성한 회사에서 제작한 것입니다.GWT EXT는 ExtJS 라이브러리를 둘러싼 GWT 래퍼입니다.GXT는 기본 GWT입니다.
어쨌든, GXT는 아직 다소 미성숙하고 GWT EXT처럼 탄탄한 커뮤니티가 부족하다고 생각합니다.그러나 미래는 GXT에 있습니다. GXT는 기본 GWT이고 실제로 ExtJS를 만든 회사에서 개발했기 때문입니다.GWT EXT는 ExtJS 라이브러리의 라이센스가 변경되면서 다소 손상되어 GWT EXT 개발 속도가 느려집니다.
전반적으로 GWT/GXT는 웹 애플리케이션 개발에 좋은 솔루션이라고 생각합니다.저는 실제로 개발을 위한 호스트 모드를 꽤 좋아합니다. 호스트 모드를 사용하면 작업이 빠르고 쉬워집니다.또한 코드를 디버그할 수 있다는 이점도 있습니다.JUnit을 사용한 단위 테스트도 매우 견고합니다.저는 아직 엔터프라이즈 애플리케이션을 테스트하기에 충분히 성숙하다고 생각되는 훌륭한 JavaScript 단위 테스트 프레임워크를 본 적이 없습니다.
GWT EXT에 대한 자세한 내용은 다음을 참조하세요.http://gwt-ext.com/
EXT GWT(GXT)에 대한 자세한 내용은 다음을 참조하세요.http://extjs.com/products/gxt/
쉽게 극복하지 못한 큰 함정은 없습니다.호스팅 모드를 많이 사용하세요.GWT-ext를 사용하면 기본 모양을 조정하지 않는 한 CSS를 직접 만질 필요가 거의 없습니다.
내 추천은 기능이 가까운 라이브러리 대신 GWT "네이티브" 위젯을 사용하는 것입니다.
검색 엔진 인덱싱 조사:예, 사이트에는 일반적으로 탐색 가능한 URL이 없습니다(일반 웹 사이트의 요소에만 위젯을 추가하는 경우 제외).하지만 기록 뒤로/앞으로 기능을 수행할 수 있습니다.
얼마 전 프로젝트에서 GWT와 GWT-ext를 함께 사용했습니다.웹 개발이 진행되면서 경험이 매우 순조롭게 진행되었지만 내 조언은 다음과 같습니다.
GWT 기본 위젯과 EXT 위젯을 혼합하지 마세요.일반적으로 이름이 동일하기 때문에(GWT.Button 또는 GWText.Button?) 정말 혼란스럽습니다.
나에게 일어난 한 가지는 실제로 코드를 원하는 것보다 더 복잡하게 만든 것 중 하나는 A) 동적으로 업데이트 가능한 패널을 원한다는 것입니다. b) Cascadable
GWT 기본 패널은 동적이며 Ext 패널은 계단식으로 연결 가능합니다.해결책?GWTExt 패널을 래핑하는 GWT.VerticalPanel...혼돈.:)
하지만 작동합니다.;)
두 번째로 ykagano의 의견입니다. 가장 큰 단점은 MVC에서 V를 잃는 것입니다.클라이언트 측 코드의 나머지 부분에서 실제 UI 클래스를 분리할 수 있지만 그래픽/웹 디자이너가 생성한 HTML 페이지를 쉽게 사용할 수는 없습니다.이는 HTML을 Java로 변환하려면 개발자가 필요하다는 것을 의미합니다.
wysiwyg UI 편집기를 사용하면 많은 시간을 절약할 수 있습니다.저는 GWTDesigner를 사용합니다.
GWT의 가장 큰 장점은 크로스 브라우저 문제를 잊을 수 있다는 것입니다.100%는 아니지만 거의 모든 통증이 사라집니다.호스트 모드 디버깅의 이점(훌륭하지만 Java 디버거와 동일하지는 않은 Firebug와 반대)과 결합되어 개발자에게 복잡한 Ajax 앱을 생성하는 데 큰 이점을 제공합니다.
아, 특히 gzip 필터를 사용하는 경우 런타임이 빠릅니다.
주제에서 약간 벗어났지만, 문제가 지속되는 경우 irc의 #gwt 채널이 매우 도움이 됩니다.
GWT는 매우 간단하고 직관적입니다.
특히 UIBinder가 출시되면서 GWT 위젯을 XML로 배치한 다음 Java로 코딩할 수 있게 되었습니다.
따라서 다른 Ajax나 Flash 디자인 도구, Silverlight 등을 사용해 본 적이 있다면 GWT를 배우기가 매우 쉽습니다.
함정은 아니더라도 가장 큰 장애물은 GWT RPC입니다.GWT를 사용하려는 이유는 GWT 비동기 RPC 때문입니다.그렇지 않으면 CSS를 사용하여 페이지 형식을 지정하는 것은 어떨까요?
GWT RPC는 서버가 페이지를 새로 고치지 않고도 서버의 데이터를 새로 고칠 수 있게 해주는 요소입니다.이는 주식 성과 모니터링(또는 현재 미국의 국가 및 공공 부채 또는 전 세계적으로 초 단위로 낙태된 태아 수)과 같은 페이지에 대한 절대 요구 사항입니다.
GWT RPC를 이해하려면 약간의 노력이 필요하지만 몇 시간만 지나면 모든 것이 명확해집니다.
그 위에, GWT RPC를 배우기 위해 약간의 노력을 기울인 후에 마침내 JSP를 RPC의 서비스 구성 요소로 사용할 수 없다는 것을 알게 되었습니다.내 블로그에는 JSP를 GWT RPC 서비스로 사용하는 방법에 대한 8부작 시리즈가 있습니다.하지만 질문하신 내용은 답변이 아닌 문제일 뿐이므로 블로그 광고는 자제하겠습니다.
그래서.나는 GWT 사용에 있어 최악의 장애물/함정은 GWT 비동기 RPC를 적절하게 배포하는 방법과 JSP 서비스를 사용하도록 활성화하는 방법을 찾는 것이라고 믿습니다.
우리는 GWT 코드베이스를 웹 디자이너로부터 얻은 HTML 웹 템플릿(GWT가 관리하기를 원하는 특정 div ID가 있는 정적 HTML 페이지)과 결합하는 데 매우 어려움을 겪었습니다.적어도 우리가 그것을 사용했을 당시에는 GWT로 코딩되지 않은 웹사이트 부분과 통합할 수 있는 GWT를 얻을 수 없었습니다.우리는 결국 성공했지만 그것은 큰 해킹이었습니다.
- 각 서비스 인터페이스에 대해 작성해야 하는 비동기 인터페이스는 GWT 컴파일러에 의해 자동으로 생성될 수 있는 인터페이스처럼 보입니다.
- 대규모 프로젝트의 경우 컴파일 시간이 길어집니다.
그러나 대규모 Javascript 프로젝트의 경우 이것이 최선의 선택입니다.
GWT 2.4는 앞서 언급한 많은 문제를 해결했으며 훌륭한 위젯 라이브러리가 베타 버전으로 출시되었습니다(Ext GWT 3.0.4 a.k.a.).GXT)는 JS lib의 래퍼가 아닌 GWT로 완전히 작성되었습니다.
남은 고통:
- CSS3 선택기 지원이 부족하므로 경우에 따라 "literal()"을 사용하여 문제를 해결할 수 있습니다.
- CSS3 및 다음과 같은 최신 브라우저 이벤트에 대한 지원 부족 전환 종료.
- Java Calendar 클래스 지원 부족(수년 후).
- JUnit4 지원 부족(5년 이상).
- Google GWT 팀의 명확한 로드맵 및 출시 일정이 부족합니다.
GWT 2.4와 관련하여, 파이어폭스 사용 GWT를 디버깅할 때 크롬을 사용하는 것보다 훨씬 빠릅니다.그리고 Firefox만 사용한다면 이 줄을 프로젝트.gwt.xml 파일
<set-property name="user.agent" value="gecko1_8" />
또한 Eclipse를 사용하는 경우 인수 -> VM 인수 아래에 다음을 추가합니다.
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
서버와 클라이언트를 나누고 인수 -> 프로그램 인수에서 다음을 사용할 수 있습니다.-codeServerPort 9997 -startupUrl http://서버/프로젝트 -noserver
또한 변경할 때마다 서버를 새로 고치지 않으려면 JRebel을 사용하세요.http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/그리고 여기 라이브 데모가 있습니다http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
한 가지 주요 함정은 때때로 특정 CSS 스타일을 사용할 수 있도록 궁극적으로 HTML 요소가 되는 항목에 ID를 명시적으로 할당해야 한다는 것입니다.예를 들어:GWT TabPanel은 tabPanel의 tabBar에 ID가 할당되고 해당 elementId에 :hover를 지정한 경우에만 tabBarItems 위로 hover를 수행합니다.
나는 다른 것에 대해 썼다. GWT의 단점 다른 곳에서는 이미 Rustyshelfs 답변으로 덮여 있습니다 :).
나는 최근 GWT에 대해 많은 작업을 수행했으며 이것이 내가 말해야 할 이유입니다.
- CSS 스타일은 가끔 까다로울 수 있습니다. IE에서는 IE 개발자 도구를 사용하고 Firefox에서는 Firebug를 사용하여 정확히 무슨 일이 일어나고 있는지 파악하면 어떤 CSS를 변경해야 하는지에 대한 명확한 아이디어를 얻을 수 있습니다.
- 트릭을 사용하여 Google에서 색인을 생성하도록 할 수 있습니다.아주 유명한 사이트는 http://examples.roughian.com/ Google에서 등급을 확인하세요.훨씬 덜 유명한 사이트는 www.salvin.in (그것을 언급하는 것을 거부할 수 없었습니다), 나는 그것을 단어로 최적화했습니다:salvin 홈페이지 (Google에서 이 세 단어를 검색하세요)
나는 GWT-EXT에 대해 잘 모르지만 타사 라이브러리를 포함할 필요가 없다고 믿습니다.
귀하의 결정에 행운이 있기를 바랍니다 :)
GWT는 기능 감지 대신 브라우저 스니핑을 수행하며 일부 브라우저(특히 새로운 브라우저)에서는 애플리케이션이 작동하지 않습니다.
다음은 문제에 대한 몇 가지 참고 자료입니다.
- google-web-toolkit 문제 2938:RFE:userAgent 문자열 "마스킹"에 대처하기 위해 user.agent 속성 제공자를 개선합니다.
- Iceweasel은 더 이상 지원되지 않나요?- Google 문서도구 도움말
- 모든 브라우저에 대한 GWT 구현
다음은 기능 감지에 대한 몇 가지 참고 자료입니다.
GWT 팀은 작년에 GWT 2.7을 출시한 것에 비해 많은 개선을 이루었습니다.GWT의 주요 약점 중 하나는 GWT 2.6 이하에서 컴파일하는 데 많은 시간이 걸린다는 것입니다.이것은 이제 사라졌습니다. GWT에는 매우 빠르고 변경 사항만 컴파일하는 증분 컴파일이 없습니다.
GWT 2.7에는 이제 (원천):
- 증분 빌드가 이제 단 몇 초만에 완료됩니다.
- 더 작고 더 정확한 SourceMaps
- GSS 지원
- JSInterop
- 뛰어난 JavaScript 성능
- 더 작은 코드 크기
신뢰할 수 있는 사실을 얻는 가장 좋은 방법은 GWT 설문조사.GWT의 가장 큰 문제 중 하나는 항상 긴 컴파일 시간이었습니다.다행히도 매우 빠르게 개선되고 있어 가까운 시일 내에 큰 문제는 되지 않을 것 같습니다.또 다른 함정은 Java가 모든 단계에서 나쁜 코더에 저항하는 더 복잡한 언어이기 때문에 GWT가 훨씬 더 복잡하다는 것입니다.또한 컴파일하면 레이어가 추가됩니다.예를 들어, js interop에는 약간의 상용구가 필요합니다.근본적인 문제는 GWT가 단순하게 설계되지 않았다는 것입니다.이것은 매우 복잡한 웹 앱을 위해 처음부터 설계되었으며 전체 커뮤니티는 쉬운 코딩보다 성능, 코드 품질, 아키텍처 등을 지속적으로 우선시합니다.
언제든지 GWT에서 js를 사용할 수 있으므로 GWT로 어려움을 겪고 있다면 js 사용을 고려하십시오.결국 GWT는 js이므로 js에서 할 수 있는 모든 작업을 GWT에서도 할 수 있습니다.실제로 대부분의 GWT 프로젝트는 js를 사용합니다.문제는 GWT가 훨씬 더 복잡하다는 것입니다.그럼에도 불구하고 때로는 추가적인 복잡성을 감수할 가치가 있습니다.
GWT 3.0이 엄청난 개선을 가져올 것이라는 점은 주목할 가치가 있습니다.
RPC 서비스 개체를 재사용합니다.
앱이 정지되는 것처럼 보이는 증상과 함께 경쟁 조건이 발생합니다.
함정 나는 1으로 달렸다.superdev 모드의 동작이 다릅니다.예:Someclass.class.getName()은 Superdev 모드에서 완벽하게 작동하며 클래스의 정규화된 이름을 반환합니다.생산 모드에서는 작동하지 않습니다.
- addWidget(widget)은 위젯의 Removefromparent()를 호출합니다.
GWT는 기술의 걸작입니다.이는 클라이언트와 서버 프로그래밍을 하나의 일관된 응용 프로그램으로 통합합니다. 즉, "레이어링" 이전에 소프트웨어가 작성된 방식과 작성되어야 하는 방식입니다.이는 다양한 기술 세트, 팀 구성원 간의 잘못된 의사소통 및 일반적으로 전체 웹 디자인 단계를 제거합니다.예술과 프로그래밍 모두요.예를 들어 모바일에 가장 가까운 것입니다.안드로이드 개발.실제로 GWT는 HTML뿐만 아니라 다양한 기본 UI를 생성하도록 설계되었습니다.이러한 분리를 보장하려면 내부 레이어를 프리젠테이션에 구애받지 않게 유지하려면 엄청난 규율이 필요합니다.
피해야 할 첫 번째 실수는 EXT-GWT(일명 GXT) 및 SmartGWT와 같은 타사 확장 프로그램을 사용하는 것입니다. 이 실수는 제가 깨닫는 데 4년이 걸렸습니다.자신만의 스타일에 투자하는 대신 예쁜 데스크톱 같은 위젯을 사용하기 시작하고 싶은 유혹이 있지만, 마침내 싫증이 날 때까지 SmartGWT에 얼마나 많은 문제가 있었는지 알 수 없습니다.간단히 말해서 핵심 GWT 기능 세트를 특정(매우 오래된) 수준에서 동결한 다음 그 위에 구축합니다.또한 느린 성능, 수많은 버그, 특히 모바일 장치에서의 호환성 기능은 말할 것도 없고 오늘날에는 그 조각난 데스크톱 모양과 느낌이 어리석어 보인다는 점을 명심하십시오.가능한 한 기본 브라우저 컨트롤에 가깝게 유지하고 싶습니다.드롭다운은 일부 사용자 정의 컨트롤이 아닌 기본 <select> 요소로 렌더링됩니다.
모바일 트렌드 덕분에 전체 UX가 더욱 단순해지고 평면화되고 있으므로 선명한 애플리케이션의 스타일을 지정하기 위해 많은 작업을 수행할 필요가 없습니다."3D" 모양을 원한다면 그라데이션도 있습니다.CSS3는 모든 것을 쉽게 만들었고 GWT는 원시 CSS와 달리 우아한 객체 지향 방식으로 이를 래핑합니다.따라서 GWT 쇼케이스의 보기 흉한 기본 컨트롤을 보고 실망하지 마십시오.GWT 팀은 개발자의 일이기 때문에 의도적으로 어떤 스타일도 제공하지 않았습니다.
나머지는 아름답고 간결한 API를 갖춘 강력한 유형의 Java로 작성된 거의 일반적인 브라우저 프로그래밍입니다.그러나 물론 코드가 브라우저 내에서 실행된다는 점을 잊지 마십시오. 따라서 모든 호출은 비동기식입니다.루프에서(일부 목록을 채우기 위해) GWT-RPC 메소드를 호출할 수는 없지만 이러한 상황이 발생하면 재귀적으로 연결해야 합니다.
GWT-RPC를 사용하지 않는 것과 같은 자칭 "안티 패턴"이 있습니다.지금까지는 나에게 좋았습니다.10년 동안.단순함이 핵심입니다.코드 우아함과 유지 관리성을 위해 약간의 성능을 희생할 생각은 단 1초도 없습니다.게다가 병목 현상이 발생하는 곳은 데이터베이스가 아닙니다.물론 클라이언트에 보내는 데이터의 양을 염두에 두십시오.
기존 가젯을 찾거나 스타일을 지정할 수 없는 경우 풍부한 HTML5 요소 세트를 읽고 언제든지 제3자 가젯을 래핑할 수 있습니다.나는 인기 있는 jQuery FullCalendar를 사용하여 이 작업을 수행했습니다.전혀 로켓 과학이 아닙니다.Google Maps 및 Google Charts와 같은 다른 모든 것에는 준공식 GWT 래퍼가 있습니다.
GWT는 완벽합니다.충분한 사랑을 받지 못하는 유일한 이유는 여전히 업계에 영향을 미치는 얼리 인터넷 수용자들이 컴퓨터 공학과 객체지향 언어 출신이 아니기 때문입니다.그들은 예술적(Photoshop/WordPress) 또는 네트워크(Perl/Python) 배경을 가지고 있습니다.
