GWT의 가장 큰 함정
저는 GWT를 사용하여 구현하기로 선택한 프로젝트의 시작/중간 단계에 있습니다.GWT(및 GWT-EXT)를 사용할 때 극복할 수 없는 중대한 함정에 부딪힌 적이 있습니까?퍼포먼스의 관점에서 보면 어떨까요?
우리가 이미 보고 들은 몇 가지 사항은 다음과 같습니다.
- Google은 콘텐츠를 인덱싱할 수 없습니다.
- CSS와 스타일링은 전반적으로 약간 엉성해 보인다.
이러한 항목에 대한 추가 피드백을 찾고 있습니다.감사합니다!
저는 GWT의 열렬한 팬입니다만, 많은 함정이 있습니다.다만, 우리가 극복한 것은 아닙니다만, 대부분은 다음과 같습니다.
문제:프로젝트가 커짐에 따라 컴파일 시간이 길어지고 컴파일하는 데 걸리는 시간도 길어집니다.20분짜리 컴파일에 대한 보고는 들어봤지만, 저는 평균 1분 정도밖에 안 돼요.
해결책: 코드를 다른 모듈로 분할하여 변경 시에만 구축하도록 개미에게 지시합니다.또, 개발중에, 1개의 브라우저만을 구축해 컴파일 시간을 큰폭으로 단축할 수 있습니다.이를 수행하려면 .gwt.xml 파일에 다음 내용을 저장합니다.
<set-property name="user.agent" value="gecko1_8" />
여기서 gecko1_8은 Firefox 2+, ie6은 IE 등입니다.
문제:호스트 모드는 (최소한 OS X에서는) 매우 느리고 JSP나 Rails 페이지 등의 편집과 브라우저에서 새로고침을 눌렀을 때 발생하는 '라이브' 변경과 거의 일치하지 않습니다.
솔루션:호스트 모드에는 메모리를 증설할 수 있지만(일반적으로 512M에 대응하고 있습니다만), 아직 느립니다.GWT를 충분히 사용할 수 있게 되면 이 기능을 사용할 수 없게 됩니다.큰 변경을 한 후 1개의 브라우저(일반적으로 20s 상당 컴파일)만을 위해 컴파일한 후 브라우저에서 새로 고침을 누릅니다.
업데이트: 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나 단순한 javascript와 같은 것에 비하면 큰 해머입니다.JS 파일만 포함하는 것보다 훨씬 더 많은 설정이 필요합니다.
솔루션:jquery와 같은 라이브러리를 사용하여 이러한 작업에 적합한 작고 간단한 작업을 수행할 수 있습니다.AJAX에서 매우 복잡한 것을 구축하거나 RPC 메커니즘을 통해 데이터를 주고받아야 할 경우 GWT를 사용하십시오.
문제:GWT 페이지를 채우려면 페이지가 처음 로드될 때 서버 호출을 해야 할 수 있습니다.사용자가 필요한 데이터를 가져오는 동안 로딩 기호를 보고 앉아 있는 것은 성가신 일일 수 있습니다.
솔루션:JSP 페이지의 경우 페이지는 HTML이 되기 전에 서버에 의해 이미 렌더링되어 있기 때문에 실제로 모든 GWT 콜을 발신하여 페이지에 프리로드하여 즉시 로드할 수 있습니다.자세한 내용은 여기를 참조해 주세요.
CSS에서 위젯을 스타일링하는 데 문제가 있었던 적이 없습니다.즉, 커스텀이든 뭐든 상관없습니다.그래서 함정이라는 게 무슨 뜻일까요?
퍼포먼스에 관해서는 컴파일된 GWT 코드는 고속이며, AJAX 콜은 페이지 전체를 새로 고치는 것보다 거의 항상 작습니다만, JAVA 백엔드를 사용하면 얻을 수 있는 네이티브 RPC 패킷은 꽤 콤팩트하지만, GWT만의 것은 아닙니다.
우리는 gwt와 거의 2년 가까이 일하고 있습니다.우리는 많은 교훈을 얻었다.델의 생각은 다음과 같습니다.
서드파티 위젯 라이브러리(특히 gwt-ext)를 사용하지 마십시오.디버깅, 개발 및 실행 시 성능을 저하시킵니다.어떻게 이런 일이 일어나는지 궁금하신 점이 있으면 저에게 직접 연락하세요.
gwt를 사용하여 앱의 동적 부분만 채우십시오.여러 필드에서 복잡한 사용자 상호 작용이 있는 경우.단, 동봉된 패널은 사용하지 마십시오.기존 재고 디자이너가 제공한 페이지를 가져옵니다.앱에 대한 컨트롤을 포함할 영역을 구분합니다.이러한 컨트롤을 onModuleLoad() 내의 페이지에 연결합니다.이렇게 하면 디자이너의 표준 페이지를 사용할 수 있을 뿐만 아니라 GWT 외부에서 모든 스타일링을 수행할 수 있습니다.
앱 전체를 하나의 표준 페이지로 빌드하지 않고 모든 부분을 동적으로 빌드합니다.2번 항목에서 제안하는 대로 하면 어차피 이런 일은 일어나지 않을 거예요.모든 것을 동적으로 구축하면 중간 규모에서 대규모 애플리케이션에 사용할 수 있는 성능과 대용량의 메모리가 손실됩니다.또, 제가 제안하는 대로 하면, Back 버튼도 잘 작동하기 때문에, 검색 엔진 색인화 등도 할 수 있습니다.
다른 논객들도 좋은 제안을 했다.제가 사용하는 경험의 법칙은 표준 웹 페이지를 만들 때처럼 페이지를 만드는 것입니다.그런 다음 역동성이 필요한 부분을 잘라냅니다.ID가 있는 요소로 대체한 다음RootPanel.get( id ).add( widget )그 지역을 메우기 위해서요.
우리가 직면한 함정:
GWT EXT와 같은 것을 사용하면 많은 마일리지를 얻을 수 있지만 JavaScript 라이브러리에서 이러한 얇은 베니어판을 사용할 때마다 디버깅 기능을 잃게 됩니다.GWT EXT 테이블 클래스에서 무슨 일이 일어나고 있는지 (InteliJ 디버거 내부에서) 확인할 수 없기 때문에 책상에 머리를 부딪친 적이 여러 번 있습니다.JavaScript Object라는 것만 알 수 있습니다.그래서 뭐가 잘못됐는지 알아내기가 좀 어렵네요
CSS를 아는 사람이 자네 팀에 없다는 것제 경험상 전문가가 아닌 것은 중요하지 않았습니다.실천에 관한 지식이 풍부하고 필요할 때 구글을 검색하기 위한 적절한 용어를 알고 있는 것만으로도 충분합니다.
브라우저 간의 디버깅.Out of Process Hosted Mode [ 1 ] [ 2 ][ 3 ]를 주시해 주세요.GWT 1.6에 도입될 예정입니다.지금은 호스트 모드로 좋은 점을 찾은 다음 다른 브라우저로 플레이할 수 있는 "컴파일/브라우즈" 버튼을 사용하면 됩니다.Windows에서 작업할 경우 FireFox에서 작업한 내용을 볼 수 있으며 FireBug를 사용하여 수정하고 개선할 수 있습니다.
IE6. IE6이 어떻게 다르게 표현하는지 놀라울 따름입니다.브라우저에 따라 가장 바깥쪽의 "뷰포트"에 스타일을 적용하여 다음과 같은 CSS 규칙을 적용했습니다.
.my-style { /* stuff that works most everywhere */ } .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
마지막으로 도움이 되는 에디터를 사용해야 합니다.인텔리J를 사용하고 있습니다.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와 도메인 오브젝트를 신중하게 설계해야 합니다.
- 필요한 모든 객체 데이터 전송
- 모든 데이터를 빠르게 가져오지 않도록 합니다.
- 또한 프록시/시리얼화 불가능한 개체를 보내지 않도록 해야 합니다.hibernate4gwt는 이러한 점에 도움이 됩니다.
- UI 설계UI를 Java(Panels, Buttons 등)로 시각화하는 것은 html보다 어렵습니다.
- 이력 지원GWT에는 이력 서브시스템이 포함되어 있지 않습니다.또한 멋진 URL이나 스테이트풀 북마크용 서브시스템도 포함되어 있지 않습니다.사용자가 직접 롤해야 합니다(단, History 토큰을 지원합니다).이것은 모든 AJAX 툴킷 AFIK에서 발생합니다.
IMHO, GWT는 이 '스레드'에서 언급된 모든 문제에 대한 즉각적인 지원을 제공하는 프레임워크를 놓치고 있습니다.
GWT EXT와 혼동하지 않도록 EXT GWT(GXT)를 사용한 프로젝트를 진행하고 있습니다.차이가 있습니다, EXT GWT는 실제로 Javascript Library ExtJs를 작성한 회사에서 제작한 것입니다.GWT EXT는 ExtJS 라이브러리 주변의 GWT 래퍼입니다.GXT는 네이티브 GWT입니다.
어쨌든 GXT는 아직 미숙하고 GWT EXT가 가지고 있는 확고한 커뮤니티가 부족하다고 생각합니다.그러나 GXT는 원어민 GWT로 실제로 ExtJ를 만든 회사가 개발한 것이어서 GWT EXT의 미래는 밝지 않다.GWT EXT는 ExtJs 라이브러리의 라이선스가 변경되어 GWT EXT의 개발이 늦어지고 있다.
전체적으로 GWT/GXT는 웹 어플리케이션 개발에 좋은 솔루션이라고 생각합니다.저는 사실 개발을 위한 호스트 모드를 매우 좋아합니다.이 모드를 사용하면 빠르고 쉽게 작업을 수행할 수 있습니다.코드를 디버깅할 수 있는 이점도 있습니다.JUnit을 사용한 유닛 테스트도 매우 견고합니다.엔터프라이즈 애플리케이션을 테스트하기에 충분히 성숙했다고 생각되는 훌륭한 JavaScript 유닛 테스트 프레임워크는 아직 본 적이 없습니다.
GWT EXT의 상세한 것에 대하여는, http://gwt-ext.com/ 를 참조해 주세요.
EXT GWT(GXT)의 상세한 것에 대하여는, http://extjs.com/products/gxt/ 를 참조해 주세요.
내가 쉽게 극복할 수 없었던 큰 함정은 없다.호스트 모드를 많이 사용합니다.GWT 익스텐트를 사용하고 있기 때문에, 박스 외관을 조정할 필요가 없는 한, CSS를 직접 만질 필요는 거의 없습니다.
기능이 가까운 라이브러리 위젯보다 GWT "네이티브" 위젯을 사용하는 것이 좋습니다.
재검색 엔진 인덱싱: 예. 일반 웹 사이트의 요소에만 위젯을 추가하는 경우를 제외하고 사이트에 일반적으로 탐색 가능한 URL이 없습니다.다만, 이력 백/전송 기능은 실행할 수 있습니다.
얼마 전 프로젝트에서 GWT와 GWT Ext를 함께 사용했습니다.웹 개발이 진행됨에 따라 이 경험은 매우 부드러워졌지만, 제 조언은 다음과 같습니다.
GWT 기본 위젯과 EXT 위젯을 함께 사용하지 마십시오.보통 이름이 같기 때문에 매우 혼란스럽다(GWT).버튼 또는 GWText.버튼)
코드를 정말로 복잡하게 만든 것은, a) 동적으로 갱신 가능한 b) 캐스케이드 가능한 패널을 원했다는 것입니다.
GWT 네이티브 패널은 동적이고 Ext 패널은 캐스케이드 가능합니다.해결책?GWT.수직 패널이 GWTExt 패널을 감싸고 있는 경우...혼돈. :)
하지만 효과가 있어;)
Ykagano의 코멘트에 따르면 MVC에서 V를 잃는 것이 가장 큰 단점입니다.클라이언트 측 코드의 나머지 부분과 진정한 UI 클래스를 분리할 수 있지만 그래픽/웹 디자이너가 생성한 HTML 페이지를 쉽게 사용할 수 없습니다.이는 HTML을 Java로 번역할 개발자가 필요하다는 것을 의미합니다.
wysiwyg UI 에디터를 구하면 많은 시간을 절약할 수 있습니다.나는 GWTDesigner를 사용한다.
GWT의 가장 큰 장점은 크로스 브라우저 문제를 잊을 수 있다는 것입니다.100%는 아니지만 거의 모든 고통을 덜어줍니다.호스트 모드 디버깅의 이점(뛰어나지만 자바 디버거와 동일하지 않은 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 서비스를 사용할 수 있도록 하는 방법을 찾는 것이라고 생각합니다.
웹 디자이너에서 가져온 HTML 웹 템플릿(GWT에서 관리하고자 하는 특정 div ID가 있는 정적 HTML 페이지)과 GWT 코드 베이스를 결합하는 데 어려움을 겪었습니다.적어도 사용 당시만 해도 GWT에서 코드화되어 있지 않은 웹 사이트의 일부와 GWT를 통합할 수 없었습니다.우리는 결국 성공했지만, 그것은 큰 해킹이었다.
- 각 서비스 인터페이스에 기입해야 하는 비동기 인터페이스는 GWT 컴파일러에 의해 자동으로 생성되었을 가능성이 있는 인터페이스와 비슷합니다.
- 대규모 프로젝트에서는 컴파일 시간이 길어진다.
그러나 대규모 Javascript 프로젝트에서는 이것이 최선의 선택입니다.
GWT 2.4는 앞서 언급한 많은 문제를 해결했으며, 훌륭한 위젯 라이브러리는 Beta(Ext GWT 3.0.4 a.k.a. GXT)에서 나온 것으로, JS lib의 래퍼가 아닌 GWT로 완전히 작성되었습니다.
남은 과제:
- CSS3 셀렉터가 지원되지 않는 경우 "literal()"을 사용하여 회피할 수 있습니다.
- CSS3 및 transition End 등의 최신 브라우저 이벤트에 대한 지원이 없습니다.
- Java Calendar 클래스 지원 없음(수년 후).
- JUnit4 지원 부족 (5년 이상)
- Google GWT 팀의 명확한 로드맵과 출시 일정이 없습니다.
GWT 2.4에 대해서는 GWT 디버깅 시 파이어폭스 사용, 크롬 사용보다 훨씬 빠릅니다.파이어폭스만을 사용하는 경우는, 이 행을 project.gwt.xml 파일에 넣는 것을 검토해 주세요.
<set-property name="user.agent" value="gecko1_8" />
또, 이클립스를 사용하고 있는 경우는, 다음의 인수를 인수아래에 추가합니다.-> VM 인수:
- Xmx512m -XX:MaxPermSize=420m -XX:Perm Size = 120m
서버와 클라이언트를 분할하여 인수 -> 프로그램 인수 -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 탭 패널은 :hover over tabBar만 수행합니다.탭 패널의 tabBar에 ID가 할당되어 있고 해당 요소Id에 :hover를 지정하는 경우의 항목.
저는 GWT의 다른 단점에 대해 다른 곳에 썼지만, 그것들은 이미 촌스러운 선반들의 답변으로 덮여 있습니다:)
저는 최근에 GWT에 대해 많은 작업을 했습니다만, 이 점은 다음과 같습니다.
- CSS 스타일링이 까다로울 수 있습니다.IE의 IE 개발자 툴과 Firefox의 firebug를 사용하여 정확히 무슨 일이 일어나고 있는지 파악하면 어떤 CSS를 변경해야 하는지 명확하게 알 수 있습니다.
- 구글이 인덱스를 작성하도록 트릭을 사용할 수 있습니다.매우 유명한 사이트는 http://examples.roughian.com/입니다. 구글에서 등급을 확인합니다.훨씬 덜 유명한 사이트는 www.salvin.in이다. 나는 그것을 단어에 최적화했다: salvin 홈페이지(이 세 단어를 구글에서 검색)
GWT-EXT에 대해서는 잘 모르지만, 서드파티 라이브러리를 포함할 필요는 없다고 생각합니다.
당신의 결정에 행운을 빕니다:)
GWT가 기능검출 대신 브라우저 스니핑을 실행하며 일부 브라우저(특히 새로운 브라우저)에서는 응용 프로그램이 작동하지 않습니다.
다음은 이 문제에 대한 몇 가지 참고 자료입니다.
- google-web-toolkit 문제 2938: RFE: user.agent property-provider를 개선하여 userAgent 문자열 "masking"에 대응
- Iceweasel이 더 이상 지원되지 않습니까? - Google 문서 도움말
- 모든 브라우저에 대한 GWT 구현
기능 검출에 관한 참조는 다음과 같습니다.
JavaScript 프레임워크 비교에서 추출 - Wikipedia
GWT 팀은 작년에 GWT 2.7을 출시하면서 많은 개선을 했습니다.GWT의 주요 약점 중 하나는 GWT 2.6 이하에서 컴파일이 오래 걸린다는 것이다.이제 GWT에는 초고속 증분 컴파일이 없으며 변경사항만 컴파일됩니다.
GWT 2.7에는 (출처)가 있습니다.
- 단 몇 초 만에 증분 빌드 가능
- 보다 콤팩트하고 정확한 소스 맵
- GSS 지원
- JSInterop
- 뛰어난 JavaScript 퍼포먼스
- 코드 사이즈가 작다
신뢰할 수 있는 사실을 얻는 가장 좋은 방법은 gwt 조사입니다.GWT의 가장 큰 문제 중 하나는 항상 긴 컴파일 시간입니다.다행히, 그것은 매우 빠르게 개선되고 있기 때문에 가까운 장래에 큰 문제는 되지 않을 것입니다.또 다른 함정은 GWT가 매우 복잡하다는 것입니다. 왜냐하면 Java는 모든 단계에서 불량 코더에 저항하는 더 복잡한 언어이기 때문입니다.또한 컴파일은 레이어를 추가합니다.예를 들어 js interop에는 약간의 보일러 플레이트가 필요합니다.근본적인 문제는 GWT가 단순하게 설계되지 않았다는 것이다.매우 복잡한 웹 어플리케이션을 위해 처음부터 설계되었으며 커뮤니티 전체가 쉬운 코딩보다 일관되게 우선 순위, 성능, 코드 품질, 아키텍처 등을 우선시합니다.
GWT에서는 언제든지 js를 사용할 수 있으므로 GWT에서 어려움을 겪고 있는 경우 js 사용을 고려해 보십시오.결국 GWT는 js이므로 GWT에서 js로 할 수 있는 모든 작업을 수행할 수 있습니다.실제로 대부분의 GWT 프로젝트는 js를 사용합니다.문제는 GWT가 훨씬 더 복잡하다는 것이다.그럼에도 불구하고 때로는 더 복잡할 가치가 있습니다.
GWT 3.0은 대폭적인 개선을 가져올 것입니다.
RPC 서비스 개체를 재사용하고 있습니다.
앱이 걸려 있는 것 같은 증상과 함께 레이스 상태를 유발합니다.
1번 함정에 부딪혔어superdev 모드에서 다른 동작.예를 들어 Someclass.class.getName()은 Superdev 모드에서 완전히 정상적으로 동작하며 클래스의 완전 수식 이름을 반환합니다.실제 가동 모드에서는, 이것은 동작하지 않습니다.
- addWidget(widget)은 위젯의 remove from parent()를 호출합니다.
GWT는 테크놀로지의 걸작입니다.클라이언트와 서버 프로그래밍을 통합하여 하나의 일관성 있는 애플리케이션으로 만듭니다.즉, 소프트웨어를 「레이어」하기 전에 작성한 방법 및 작성해야 하는 방법입니다.다양한 스킬 세트, 팀원 간의 커뮤니케이션 오류, 그리고 일반적으로 웹 디자인 단계 전체(예술 및 프로그래밍)를 제거합니다.모바일과 가장 가까운 거리입니다.안드로이드 개발사실 GWT는 HTML뿐만 아니라 다양한 네이티브 UI를 생성하도록 설계되어 있습니다.단, 이러한 디커플링을 확실히 하기 위해서는, 내부 레이어의 프레젠테이션에 의존하지 않는, 매우 엄격한 규율이 필요합니다.
제가 깨닫기까지 4년이 걸렸던 첫 번째 실수는 EXT-GWT나 SmartGWT와 같은 서드파티 확장을 사용하는 것입니다.자신의 스타일링에 투자하지 않고 데스크톱 같은 예쁜 위젯을 사용하기 시작하는 것은 매우 유혹적이지만, 스마트GWT에 얼마나 많은 문제가 있었는지 마침내 질릴 때까지 알 수 없다.즉, 코어 GWT 피처 세트를 특정(매우 오래된) 레벨로 동결하고 그 위에 구축합니다.또, 특히 모바일 디바이스의 퍼포먼스나 버그, 호환성 기능의 저하는 말할 것도 없고, 데스크탑의 외관이나 느낌도 우스꽝스러워 보인다는 것도 잊지 말아 주세요.가능한 한 네이티브브라우저 컨트롤에 접근해야 합니다.예를 들어 드롭다운은 커스텀 페인팅된 컨트롤이 아닌 네이티브 <select> 요소로 렌더링됩니다.
모바일 트렌드 덕분에 UX 전체가 심플해지고 평평해지기 때문에 선명해 보이는 어플리케이션을 스타일링하기 위해 많은 작업을 할 필요가 없습니다."3D" 모양을 원하는 경우 그라데이션도 있습니다.CSS3는 모든 것을 쉽게 만들었으며 GWT는 원시 CSS와 달리 우아한 객체 지향 방식으로 포장했습니다.따라서 GWT Showcase에서 보기 흉한 베어본 컨트롤을 보고 낙담하지 마십시오.GWT 팀은 개발자의 일이기 때문에 일부러 스타일링을 제공하지 않았습니다.
The rest is pretty much conventional browser programming in strongly typed Java with beautiful concise APIs. But of course never forgetting your code runs inside the browser, so all of the calls are asynchronous e.g. you cannot call GWT-RPC methods in a loop (to populate some list), but need to recursively chain them if you ever come to to this situation.
There are some self-proclaimed "anti-patterns" like don't use GWT-RPC. It's been good to me so far: for 10 years. Simplicity is key. I wouldn't think even a second to sacrifice some marginal performance for code elegance and maintainability. besides this is not where your bottlenecks would be - in the database. Of course mind how much data you are sending to the client.
And if you cannot find or style the existing gadget - read rich HTML5 element set, you can always wrap a third-party one. I did it with a popular jQuery FullCalendar. Not rocket science at all. Everything else like Google Maps and Google Charts has semi-official GWT wrappers.
GWT is perfect. The only reason it doesn't get enough love is because early Internet adopters who still influence the industry didn't come from Computer Science and object-oriented languages to appreciate them. They have either artistic (Photoshop/WordPress) or network (Perl/Python) background.
ReferenceURL : https://stackoverflow.com/questions/99866/biggest-gwt-pitfalls
'programing' 카테고리의 다른 글
| javax.transaction 입니다.트랜잭션 vs org.springframework.transaction.annotation.트랜잭션 (0) | 2022.07.10 |
|---|---|
| C++에 헤더 파일을 포함할 때 꺽쇠 괄호 < >와 큰따옴표 "의 차이가 있습니까? (0) | 2022.07.10 |
| getter에서 선택한 속성 가져오기 (0) | 2022.07.10 |
| vue-timeout(vue-timeout:모듈을 찾을 수 없습니다. (0) | 2022.07.10 |
| 쉼표로 구분된 문자열을 분할하려면 어떻게 해야 합니까? (0) | 2022.07.10 |