가장 큰 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와 협력 해 왔습니다. 우리는 많은 교훈을 얻었습니다. 우리가 생각하는 것은 다음과 같습니다.
타사 위젯 라이브러리, 특히 gwt-ext를 사용하지 마십시오. 디버깅, 개발 및 런타임 성능이 저하됩니다. 어떻게되는지 궁금한 점이 있으면 저에게 직접 연락하십시오.
gwt를 사용하여 앱의 동적 부분 만 채우십시오. 따라서 많은 필드와 복잡한 사용자 상호 작용이있는 경우 그러나 함께 제공되는 패널을 사용하지 마십시오. 기존 스톡 디자이너 제공 페이지를 가져 가십시오. 앱의 컨트롤이 포함될 영역을 개척하십시오. 이 컨트롤을 onModuleLoad () 내의 페이지에 연결하십시오. 이렇게하면 디자이너의 표준 페이지를 사용하고 gwt 외부의 모든 스타일을 수행 할 수 있습니다.
전체 앱을 하나의 표준 페이지로 빌드하지 말고 모든 조각을 동적으로 빌드하십시오. 2 번 항목에서 제안한 내용을 수행해도 어쨌든 발생하지 않습니다. 모든 것을 동적으로 구축하면 성능을 저하시키고 중대형 앱에 막대한 양의 메모리를 소비합니다. 또한 내가 제안하는 것을하면 뒤로 버튼이 잘 작동하므로 검색 엔진 색인 등이 있습니다.
다른 논평자들도 좋은 제안을했다. 내가 사용하는 기본 규칙은 표준 웹 페이지를 수행하는 것처럼 페이지를 만드는 것입니다. 그런 다음 역동적이어야하는 조각을 개척하십시오. ID가있는 요소로 교체 한 다음 RootPanel.get( id ).add( widget )해당 영역을 채우는 데 사용하십시오 .
우리가 겪은 함정 :
GWT EXT와 같은 것을 사용하면 많은 마일리지를 얻을 수 있지만 JavaScript 라이브러리 위에서 이런 종류의 얇은 베니어를 사용할 때마다 디버깅 기능이 손실됩니다. GWT EXT 테이블 클래스에서 발생하는 일을 (IntelliJ 디버거 내에서) 검사 할 수 없기 때문에 책상에 머리를 두 번 이상 shed습니다 ...보실 수있는 것은 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는 데이터 바인딩 / 검증 지원을 기본적으로 제공하지는 않지만이 영역에 일부 프로젝트가 등장하기 시작했습니다. 당신은 이것을 많이 쓰는 것을 보게 될 것입니다 :
텍스트 필드 fname, faddress; ... fname.setText (person.getName ()); faddress.setText (person.getAddress ()); ...
- 게으른 로딩. gwt가 클라이언트 측에 있기 때문에 지연 로딩은 실제로 옵션이 아닙니다. RPC와 도메인 객체를 신중하게 설계해야합니다.
- 필요한 모든 객체 데이터를 보내십시오
- 모든 데이터를 열심히 가져 오는 것을 피하십시오
- 또한 프록시 / 직렬화 할 수없는 객체를 보내지 않도록해야합니다. hibernate4gwt 는 이러한 점들에 도움을 줄 수 있습니다.
- UI design. It is harder to visualize an UI in java (Panels, Buttons, etc) than in html.
- History support. GWT does not ship with a History subsystem, nor does it ship with any subsystem for nice urls or statefull bookmarking. You'll have to roll your own (although it has support for History tokens, which is a start). This happens with all AJAX toolkits AFAIK.
IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.
I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.
Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.
Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.
For more information on GWT EXT: http://gwt-ext.com/
For more information on EXT GWT (GXT): http://extjs.com/products/gxt/
No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily. As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.
My recommendation is to use a GWT "native" widget over a library one where they are close in features.
Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.
I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:
Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)
One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was a) dynamically updatable b) cascadable
GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)
But hey, it works. ;)
I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.
Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.
The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.
Oh and its fast at runtime, especially if you use a gzip filter.
Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.
GWT is pretty straight-forward and intuitive.
Especially with the release of UIBinder to allow GWT widgets to be laid out in XML and then coded-behind in Java.
So if you have used other Ajax or Flash design tools, or Silverlight, etc, GWT is very easy to learn.
The major hurdle, if not pitfall, is GWT RPC. The very reason you wish to use GWT is because of GWT async RPC. Otherwise, why not just rely on css to format your page?
GWT RPC is that element that allows your server to refresh data on your server without having to refresh the page. This is an absolute requirement for pages such as stock performance monitoring (or the current national and public debt of the US or the number of unborn babies aborted worldwide by the second).
GWT RPC takes some effort to understand but given a few hours, it should come all clear.
Above that, after putting in some effort to learn GWT RPC, you finally discover that you cannot use JSPs as the service component for RPC, unless ... I have an 8 part (I think) series on my blog on how to use JSP as the GWT RPC servicer. However, since you had not asked for answers but just issues, I shall desist from advertising my blog.
So. I very much believe that the worst roadblocks/pitfalls to using GWT is finding out how to properly deploy GWT async RPC and how to enable it to use JSP servicers.
We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.
- The Async interface you have to write for each service interface looks like something that could have been automatically generated by the GWT compiler.
- Compile times become long for large projects
But for a large Javascript project it's the best choice
GWT 2.4 has fixed many of the aforementioned issues and a great widget library is just coming out of Beta (Ext GWT 3.0.4 a.k.a. GXT), which is written completely in GWT, not a wrapper of a JS lib.
Remaining pain:
- Lack of CSS3 selector support, you can use "literal()" in some cases to get around it.
- Lack of support for CSS3 and modern browser events like transitionEnd.
- Lack of Java Calendar class support (many years later).
- Lack of JUnit4 support (5 years and counting).
- Lack of clear road map and release schedule from Google GWT team.
Regarding GWT 2.4, Use Firefox when debugging GWT, it alot more faster then using chrome. And if you'll using only firefox, consider putting this line in your project.gwt.xml file
<set-property name="user.agent" value="gecko1_8" />
Also, If you're using eclipse, then add the following under arguments -> VM arguments:
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
You can divide your server and client, and use the following under arguments -> Program arguments: -codeServerPort 9997 -startupUrl http://yourserver/project -noserver
Also, to prevent refreshing your server on each change, use JRebel http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ And here's a live demo http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.
I wrote about some other disadvantages of GWT elsewhere, but they are already covered by rustyshelfs answer :).
I have done a lot of work on GWT recently, and this is wht i have to say:
- CSS styling is tricky only sometimes, use IE developer tool in IE and firebug in Firefox to figure out what exactly is happening and you will get a clear idea of what css needs to be changed
- You can use tricks to get google to index it. A very famous site is http://examples.roughian.com/ check its ratings at google. A far less famous site is www.salvin.in (couldnt resist to mention that), i optimised it to words: salvin home page (search google for these three words)
I do not know much about GWT-EXT, But i too am of the belief that there is no need to include Third party libraries.
Best of luck on your decision :)
GWT does Browser Sniffing instead of Feature Detection and your application will not work on some browsers (specially new ones)
Here are some references of the problem:
- google-web-toolkit Issue 2938: RFE: improve the user.agent property-provider to cope for userAgent string "masking"
- Iceweasel no longer supported? - Google Docs Help
- GWT implementations for every browser
Here are some references to Feature Detection:
- Browser Detecting (and what to do Instead)
- Feature Detection: State of the Art Browser Scripting
- Browser Feature Detection
Extracted from Comparison of JavaScript frameworks - Wikipedia
The GWT team make a lot of great improvements in to last year releasing GWT 2.7. One major weakness of GWT was that compilation takes to much time in GWT 2.6 and below. This is now gone GWT has not incremental compile which is super fast and compiles only the changes.
GWT 2.7 now has (Source):
- Incremental builds now just seconds
- More compact, more accurate SourceMaps
- GSS support
- JSInterop
- Great JavaScript Performance
- Smaller Code Size
The best way to get reliable facts are from the gwt survey. One of the biggest issues with GWT has always been a long compile time. Fortunately, it's improving very quickly so it won't be a significant issue in the near future. Another pitfall is that GWT is dramatically more complicated because Java is a more complicated language that resists bad coders every step of the way. In addition, compiling adds a layer. For example, js interop requires a little boilerplate. The fundamental issue is that GWT wasn't designed to be simple. It was designed from the ground up for extremely complicated web apps and the entire community consistently prioritizes, performance, code quality, architecture etcetera over easy coding.
Remember that you can use js in GWT at any point so if you are struggling with GWT consider using js. At the end of the day GWT is js so you can do anything in GWT that you can in js. In fact, most GWT projects use js. The problem is that GWT is drastically more complicated. Nevertheless, it's sometimes worth the extra complexity.
It's worth noting that GWT 3.0 will bring massive improvements.
Re-using RPC service objects.
It causes race conditions with symptoms that look like the app hanging.
Pitfalls I ran into 1. Different behaviour in superdev mode. E.g. Someclass.class.getName() works absolutely fine in Superdev mode and returns the fully qualified name of the class. In productive mode this does not work.
- addWidget(widget) will call widget's removefromparent()
GWT is a technology masterpiece. It unites client and server programming making it one coherent application - the way software was written before "layering", and the way it should be written. It eliminates different skills sets, miscommunication between team members, and generally the whole Web Design phase: both the artistic and programming. And it is the closest you'd get to mobile e.g. Android development. In fact GWT was designed to generate different native UIs, not just HTML. Though it requires enormous discipline to ensure such decoupling - to keep your inner layers presentation-agnostic.
The first mistake you should avoid, which took me four years to realize, is using third-party extensions like EXT-GWT aka GXT and SmartGWT. It is very tempting to start using their pretty desktopish widgets instead of investing in your own styling, but I cannot tell how many problems I had with SmartGWT until I finally got fed up. In short it freezes the core GWT feature set at the certain (pretty outdated) level and then builds on top of it. Also keep in mind, that chiseled desktop look and feel looks silly nowadays, not to mention the sluggish performance, tons of bugs, and compatibility features - especially on mobile devices. You want to stay as close to the native browser controls, as possible i.e. dropdowns rendered as native <select> elements, not some custom-painted controls.
Thanks to mobile trends the whole UX is becoming simpler and flatter, so you don't need to do much to style a sharp-looking application. Though if you want "3D" look, there are also gradients. CSS3 made everything easy, and GWT wraps it an elegant object-oriented manner unlike the raw CSS. So don't be discouraged by looking at rather ugly barebones controls in the GWT Showcase. The GWT team intentionally didn't offer any styling, because it it the developer's job.
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.
참고URL : https://stackoverflow.com/questions/99866/biggest-gwt-pitfalls
'Programing' 카테고리의 다른 글
| 긴 줄을 파이썬으로 감싼다 (0) | 2020.05.14 |
|---|---|
| DOS의 재귀 디렉토리 목록 (0) | 2020.05.14 |
| 힘내 : "현재 지점에 없습니다." (0) | 2020.05.14 |
| Windows 용 최고의 경량 웹 서버 (정적 컨텐츠 만) (0) | 2020.05.14 |
| 문자열이 양의 정수인지 확인 (0) | 2020.05.14 |