가장 큰 GWT 함정? [닫은]

GWT를 사용하여 구현하기로 선택한 프로젝트의 시작 / 중간에 있습니다. 누구도 극복 할 수없는 GWT (및 GWT-EXT)를 사용할 때 큰 함정을 경험 한 적이 있습니까? 성능 관점에서 어떻습니까?

우리가 보거나 들어 본 몇 가지 사항은 다음과 같습니다.

• Google이 콘텐츠를 색인 할 수 없습니다
• CSS와 스타일은 일반적으로 약간 색다른 것으로 보입니다.

이 항목들에 대한 추가 피드백도 찾으십시오. 감사!

나는 거대한 GWT 팬이라고 말하면서 시작할 것입니다.하지만 많은 함정이 있지만 대부분 극복 할 수는 없었습니다.

문제 : 프로젝트가 커질수록 컴파일 시간이 길어지고 컴파일 시간이 길어집니다. 나는 20 분 컴파일 보고서에 대해 들었지만 내 평균은 약 1 분입니다.

해결 방법 : 코드를 별도의 모듈로 나누고 개미에게 변경 될 때만 빌드하도록 지시하십시오. 또한 개발하는 동안 하나의 브라우저 만 빌드하면 컴파일 시간을 크게 단축 할 수 있습니다. 이것을 .gwt.xml 파일에 넣으면됩니다 :

<set-property name="user.agent" value="gecko1_8" />

gecko1_8이 Firefox 2 이상인 경우, 즉 6은 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와 협력 해 왔습니다. 우리는 많은 교훈을 얻었습니다. 우리가 생각하는 것은 다음과 같습니다.

1. 타사 위젯 라이브러리, 특히 gwt-ext를 사용하지 마십시오. 디버깅, 개발 및 런타임 성능이 저하됩니다. 어떻게되는지 궁금한 점이 있으면 저에게 직접 연락하십시오.

2. gwt를 사용하여 앱의 동적 부분 만 채우십시오. 따라서 많은 필드와 복잡한 사용자 상호 작용이있는 경우 그러나 함께 제공되는 패널을 사용하지 마십시오. 기존 스톡 디자이너 제공 페이지를 가져 가십시오. 앱의 컨트롤이 포함될 영역을 개척하십시오. 이 컨트롤을 onModuleLoad () 내의 페이지에 연결하십시오. 이렇게하면 디자이너의 표준 페이지를 사용하고 gwt 외부의 모든 스타일을 수행 할 수 있습니다.

3. 전체 앱을 하나의 표준 페이지로 빌드하지 말고 모든 조각을 동적으로 빌드하십시오. 2 번 항목에서 제안한 내용을 수행해도 어쨌든 발생하지 않습니다. 모든 것을 동적으로 구축하면 성능을 저하시키고 중대형 앱에 많은 양의 메모리를 소비합니다. 또한 내가 제안하는 것을하면 뒤로 버튼이 잘 작동하므로 검색 엔진 색인 등이 있습니다.

다른 논평자들도 좋은 제안을했다. 내가 사용하는 기본 규칙은 표준 웹 페이지를 수행하는 것처럼 페이지를 만드는 것입니다. 그런 다음 역동적이어야하는 조각을 개척하십시오. ID가있는 요소로 교체 한 다음 RootPanel.get( id ).add( widget )해당 영역을 채우는 데 사용하십시오 .

우리가 겪은 함정 :

• GWT EXT와 같은 것을 사용하면 많은 마일리지를 얻을 수 있지만 JavaScript 라이브러리 위에서 이런 종류의 얇은 베니어를 사용할 때마다 디버깅 기능이 손실됩니다. GWT EXT 테이블 클래스에서 무슨 일이 일어나고 있는지 (IntelliJ 디버거 내부에서) 검사 할 수 없기 때문에 책상에 머리를 두 번 이상 내 밀었습니다 ...보실 수있는 것은 JavaScriptObject입니다. 이로 인해 무엇이 잘못되었는지 파악하기가 매우 어렵습니다 ...

• 팀에 CSS를 아는 사람이 없습니다. 내 경험상, 그 사람이 전문가가 아니었다는 것은 문제가되지 않았다. 그는 좋은 실무 지식을 가지고 있고 필요할 때 구글에 대한 올바른 용어를 알고있다.

• 여러 브라우저에서 디버깅 Out of Process Hosted Mode [ 1 ] [ 2 ] [ 3 ]를 주시하십시오. GWT 1.6에 들어 오길 바랍니다 ... 지금은 Hosted 모드로 작업을 끝내고 "Compile / Browse"버튼을 사용해야합니다. 다른 브라우저에서 플레이 할 수 있습니다. 나에게있어 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 만 처음에 다운로드됩니다. 나머지는 필요에 따라 다운로드됩니다
• In-Browser Hosted Mode (브라우저 내 호스팅 모드)-논의 된 호스팅 모드 속도 문제를 처리 할 수 ​​있습니다.
• "컴파일러 최적화"-더 빠른 컴파일

Google I / O에서 GWT 2.0 미리보기 비디오

"이길 수없는"것이 아니라 기본적인 것에 대한 약간의 고통.

날짜 처리 :

GWT는 더 이상 사용되지 않으므로 java.util.Date클라이언트 측의 날짜를 처리 할 때 예기치 않은 동작이 발생할 수 있습니다. java.util.CalendarGWT는 지원하지 않습니다. 자세한 내용은 여기를 참조하십시오 .

관련 문제 예 :

• GWT java.util.Date 직렬화 버그
• GWT에서 날짜 세부 정보 (일, 월, 년) 가져 오기
• GWT에서 클라이언트 측 시간대 지원

이미 언급 한 사항에 몇 가지 요점을 추가하겠습니다.

• 데이터 바인딩 / 검증 GWT는 데이터 바인딩 / 검증 지원을 기본적으로 제공하지는 않지만이 영역에 일부 프로젝트가 등장하기 시작했습니다. 당신은 이것을 많이 쓰는 것을 보게 될 것입니다 :

텍스트 필드 fname, faddress;
...
fname.setText (person.getName ());
faddress.setText (person.getAddress ());
...

• 게으른 로딩. gwt가 클라이언트 측에 있기 때문에 지연 로딩은 실제로 옵션이 아닙니다. RPC와 도메인 객체를 신중하게 설계해야합니다.
  • 필요한 모든 객체 데이터를 보내십시오
  • 모든 데이터를 열심히 가져 오는 것을 피하십시오
  • 또한 프록시 / 직렬화 할 수없는 객체를 보내지 않도록해야합니다. hibernate4gwt 는 이러한 점들에 도움을 줄 수 있습니다.
• UI 디자인. html보다 자바 (패널, 버튼 등)로 UI를 시각화하는 것이 더 어렵습니다.
• 역사 지원. GWT는 히스토리 서브 시스템과 함께 제공되지 않으며 멋진 URL이나 상태 전체 북마크를위한 서브 시스템과 함께 제공되지 않습니다. 히스토리 토큰을 지원하지만 시작은 자신의 롤을해야합니다. 이것은 모든 AJAX 툴킷 AFAIK에서 발생합니다.

IMHO, GWT에는이 '스레드'에 언급 된 모든 문제에 대해 즉시 지원되는 프레임 워크가 없습니다.

EXT GWT (GXT)를 사용하여 GWT EXT와 혼동하지 않는 프로젝트를 진행하고 있습니다. 차이점은 EXT GWT는 ExtJS를 자바 스크립트 라이브러리로 작성한 회사가 실제로 만든 것입니다. GWT EXT는 ExtJS 라이브러리 주변의 GWT 래퍼입니다. GXT는 기본 GWT입니다.

어쨌든 GXT는 여전히 미숙하고 GWT EXT가 느끼는 견고한 커뮤니티가 부족합니다. 그러나 미래는 GXT의 기본 GWT이며 실제로 ExtJS를 만든 회사가 개발했기 때문에 GXT와 함께합니다. 라이센스가 ExtJS 라이브러리에서 변경되면 GWT EXT가 다소 손상되어 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) 캐스케이드 가능한 패널을 원한다는 것입니다.

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의 서비스 컴포넌트로 사용할 수 없다는 것을 발견했습니다. GWT RPC 서비스 제공자. 그러나 귀하가 답변을 요구하지 않고 문제 만 제기했기 때문에 블로그를 광고하는 것이 바람직합니다.

그래서. GWT를 사용하는 데있어 최악의 장애물은 GWT 비동기 RPC를 올바르게 배포하는 방법과 JSP 서비스 제공자를 사용하도록 설정하는 방법을 찾는 것입니다.

우리는 웹 디자이너 (GWT가 관리하기를 원하는 특정 div id를 가진 정적 HTML 페이지)에서 가져온 HTML 웹 템플릿과 GWT 코드베이스를 결합하는 데 매우 어려움을 겪었습니다. 적어도 우리가 그것을 사용할 때, 우리는 GWT가 GWT로 코딩되지 않은 웹 사이트의 일부와 통합 할 수 없었습니다. 우리는 결국 작동했지만 큰 해킹이었습니다.

• 각 서비스 인터페이스에 대해 작성해야하는 비동기 인터페이스는 GWT 컴파일러가 자동으로 생성 할 수있는 것처럼 보입니다.
• 대규모 프로젝트의 경우 컴파일 시간이 길어집니다.

그러나 대규모 Javascript 프로젝트의 경우 최선의 선택입니다.

GWT 2.4는 위에서 언급 한 많은 문제를 해결했으며 훌륭한 위젯 라이브러리는 베타 (Ext GWT 3.0.4 일명 GXT)에서 나오며 JS 라이브러리의 래퍼가 아닌 GWT로 완전히 작성됩니다.

남은 고통 :

• CSS3 선택기 지원이 부족하여 경우에 따라 "literal ()"을 사용할 수 있습니다.
• CSS3 및 transitionEnd 와 같은 최신 브라우저 이벤트에 대한 지원 부족 .
• Java Calendar 클래스 지원 부족 (몇 년 후)
• JUnit4 지원 부족 (5 년 및 계산).
• Google GWT 팀의 명확한 도로지도 및 출시 일정이 없습니다.

GWT 2.4와 관련하여 GWT를 디버깅 할 때 Firefox 를 사용하면 크롬을 사용하는 것보다 훨씬 빠릅니다. firefox 만 사용하는 경우 project.gwt.xml 파일 에이 줄을 넣는 것을 고려 하십시오.

<set-property name="user.agent" value="gecko1_8" />

또한 이클립스를 사용하는 경우 인수-> VM 인수 아래에 다음을 추가하십시오.

-Xmx512m -XX : MaxPermSize = 1024m -XX : PermSize = 1024m

서버와 클라이언트를 나누고 인수-> 프로그램 인수에서 다음을 사용할 수 있습니다. -codeServerPort 9997 -startupUrl http : // yourserver / project -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의 다른 단점에 대해 썼지 만 이미 녹슨 선반 답변으로 덮여 있습니다 :).

나는 최근에 GWT에 대해 많은 작업을 수행했으며, 이것이 내가 말해야 할 내용입니다.

1. CSS 스타일링은 때때로 까다로울 수 있습니다 .IE의 IE 개발자 도구와 Firefox의 파이어 버그를 사용하여 정확히 무슨 일이 일어나고 있는지 파악하면 CSS를 변경 해야하는 것에 대한 명확한 아이디어를 얻을 수 있습니다
2. 트릭을 사용하여 Google이 색인을 생성하도록 할 수 있습니다. 매우 유명한 사이트는 http://examples.roughian.com/ 이며 Google에서 등급을 확인하십시오. 훨씬 덜 유명한 사이트는 www.salvin.in (이를 언급 할 수 없음)이며, 나는 그것을 단어에 최적화했습니다 : salvin home page (이 세 단어에 대한 Google 검색)

GWT-EXT에 대해 많이 알지 못하지만 타사 라이브러리를 포함 할 필요가 없다고 생각합니다.

당신의 결정에 행운을 빕니다 :)

GWT는 기능 감지 대신 브라우저 스니핑을 수행하며 일부 브라우저 (특히 새 브라우저)에서는 응용 프로그램이 작동하지 않습니다.

다음은 문제에 대한 참조입니다.

• google-web-toolkit 문제 2938 : RFE : userAgent 문자열 "마스킹"에 대처하기 위해 user.agent 속성 제공 업체 개선
• 얼음 족제비가 더 이상 지원되지 않습니까? -Google 문서 도구 도움말
• 모든 브라우저에 대한 GWT 구현

다음은 기능 감지에 대한 참조입니다.

• 브라우저 감지 (및 대신 수행 할 작업)
• 기능 탐지 : 최첨단 브라우저 스크립팅
• 브라우저 기능 감지

JavaScript 프레임 워크 비교 에서 추출-Wikipedia

GWT 팀은 작년에 GWT 2.7을 발표하여 크게 개선했습니다. GWT의 한 가지 주요 단점은 GWT 2.6 이하에서 컴파일에 많은 시간이 걸린다는 것입니다. 이것은 이제 사라졌습니다 GWT는 증분 컴파일을하지 않았으며 매우 빠르며 변경 사항 만 컴파일합니다.

GWT 2.7에는 이제 ( Source )가 있습니다 :

• 이제 몇 초만에 증분 빌드
• 더 작고 정확한 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 모드에서 완벽하게 작동하며 클래스의 정규화 된 이름을 반환합니다. 생산 모드에서는 작동하지 않습니다.

2. addWidget (widget)은 위젯의 removefromparent ()를 호출합니다.

GWT는 기술 걸작입니다. 클라이언트와 서버 프로그래밍을 통합하여 소프트웨어를 "계층화"전에 작성한 방식과 작성 방식을 일관된 응용 프로그램으로 만듭니다. 다른 기술 세트, 팀 구성원 간의 잘못된 커뮤니케이션 및 일반적으로 예술 및 프로그래밍의 전체 웹 디자인 단계를 제거합니다. 그리고 그것은 안드로이드 개발과 같이 모바일에 가장 가까운 곳입니다. 실제로 GWT는 HTML뿐만 아니라 다른 고유 UI를 생성하도록 설계되었습니다. 이러한 분리를 보장하려면 내부 규칙을 무시해도됩니다.

4 년이 걸렸던 첫 번째 실수는 EXT-GWT, 즉 GXT 및 SmartGWT와 같은 타사 확장을 사용하는 것입니다. 자신의 스타일에 투자하는 대신 예쁜 데스크탑 위젯을 사용하는 것이 매우 유혹적이지만 최종적으로 지칠 때까지 SmartGWT에 얼마나 많은 문제가 있었는지 알 수 없습니다. 간단히 말해서 핵심 GWT 기능 세트를 특정 (꽤 구식) 레벨로 정지시킨 다음 그 위에 빌드합니다. 또한 치즐을 끄는 데스크탑 모양과 느낌은 오늘날 모바일 기기의 느린 성능, 수많은 버그 및 호환성 기능은 말할 것도없이 어리석은 것처럼 보입니다. 가능한 경우 기본 브라우저 컨트롤에 가깝게 유지하려고합니다. 즉, 일부 사용자 정의 컨트롤이 아니라 기본 <select> 요소로 렌더링 된 드롭 다운입니다.

모바일 트렌드 덕분에 전체 UX가 더 단순하고 평평 해지고 있으므로 날카로운 응용 프로그램의 스타일을 지정하기 위해 많은 작업을 수행 할 필요가 없습니다. "3D"모양을 원한다면 그래디언트도 있습니다. CSS3는 모든 것을 쉽게 만들었으며 GWT는 원시 CSS와 달리 객체 지향 방식을 우아하게 감 쌉니다. 따라서 GWT 쇼케이스에서 오히려 못생긴 베어 본 컨트롤을 보면서 낙심하지 마십시오. GWT 팀은 의도적으로 개발자의 작업이기 때문에 어떤 스타일도 제공하지 않았습니다.

나머지는 아름다운 간결한 API를 사용하여 강력하게 유형이 지정된 Java에서 거의 일반적인 브라우저 프로그래밍입니다. 그러나 물론 코드가 브라우저 내에서 실행되는 것을 잊지 마십시오. 모든 호출은 비동기 적입니다. 예를 들어 루프에서 GWT-RPC 메소드를 호출 할 수는 없지만 (일부 목록을 채우려면) 재귀 적으로 연결해야합니다. 상태.

GWT-RPC를 사용하지 않는 것과 같이 자체적으로 선언 된 "반 패턴"이 있습니다. 지금까지 10 년 동안 나에게 좋았습니다. 단순성이 핵심입니다. 코드 우아함과 유지 보수성을 위해 약간의 성능을 희생하는데도 1 초도 걸리지 않을 것입니다. 이외에도 데이터베이스에서 병목 현상이 발생하지 않습니다. 물론 클라이언트에 얼마나 많은 데이터를 보내고 있는지 염두에 두십시오.

기존 가젯을 찾거나 스타일을 지정할 수없는 경우 풍부한 HTML5 요소 세트를 읽으면 언제든지 타사를 래핑 할 수 있습니다. 인기있는 jQuery FullCalendar로 수행했습니다. 로켓 과학이 아닙니다. Google지도 및 Google 차트와 같은 모든 것에는 준 공식 GWT 래퍼가 있습니다.

GWT는 완벽합니다. 그것이 충분히 사랑을 얻지 못하는 유일한 이유는 여전히 업계에 영향을 미치는 초기 인터넷 채택자가 컴퓨터 과학과 객체 지향 언어에서 온 것이 아니기 때문입니다. 그들은 예술적 (Photoshop / WordPress) 또는 네트워크 (Perl / Python) 배경을 가지고 있습니다.