[GWT Wiki] Instant Hosted Mode
1월 23일자로 GWT Wiki 에 새로운 글이 하나 올라왔습니다.
글의 제목은 InstantHostedMode 입니다. 찬찬히 살펴 볼까욤~
언제쯤 GWT 1.6 이 나와서 테스트하기 편한 환경을 마련해 줄까요...
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
JavaScriptObject 와 관련된 글인 것 같은데 조금 더 읽어봐야겠습니다.Background
The JavaScriptObject class has been an extremely useful concept because it provides zero-overhead interoperation with external (typically, non-GWT) JavaScript while adding additional value to external JavaScript objects by representing them as actual Java types that are amenable to refactoring, code completion, and Javadoc-style documentation. However, subclassing JavaScriptObject was not generally supported before GWT 1.5 because we weren't sure if it was the right solution, or if we might need to evolve it in breaking ways. This document describes the "old model" prior to GWT 1.5, and the new model, overlay types, which shipped in GWT 1.5 as well as extensions to overlay types that will first ship in GWT 2.0.
The old model used two very different approaches for hosted mode and web mode, but in both cases the point of interest was the boundary point between Java and JavaScript code, when a JavaScript object passes into "the Java world". This boundary point was most often the return value of a JSNI function, but could also occur when a JSNI function accessed Java code through a field assignment, or by passing parameters to a Java function called from JSNI.
In hosted mode, we created an instance of JavaScriptObject (or a JavaScriptObject subclass) as we marshalled the value from JavaScript to Java. This instance served as a Java wrapper for the underlying JavaScript object. It had strong type identity, and handled instanceof, casts, and polymorphic calls through the normal Java mechanisms.
In web mode, we did not wrap the underlying JavaScript object in the traditional sense with a peer object, because that would have impeded performance. Instead, we decorated the underlying JavaScript object with sufficient type information to handle runtime type checks and polymorphic dispatch as needed.
GWTEventService is an event-based client-server communication framework. It uses GWT-RPC and the Comet / server-push technique. The client side offers a high-level API with opportunities to register listeners to the server like to a GUI component. Events can be added to a context/domain on the server side and the listeners on the client side get informed about the incoming events. The server side is completely independent of the client implementation and is highly configurable. Domains can be defined to decide which events are important for the different contexts.
Advantages
- Encapsulation of the client-server communication
- High-level API with listeners and events
- Only one open connection for event listening
- Reduction of server calls
- Reduction of connection peaks
- Events are returned directly when the event has occurred (instead of polling)
- Events are bundled to reduce server calls
- Based on the GWT-RPC mechanism
- Automatic timeout recognition and handling
- Extensible architecture
In 1.5, GWTShellServlet served resources directly off the classpath (for public files), or generated files from a temporary location. This has the advantage of allowing fast refresh and resource updating, and making things "easy". However, it has the downside of not leaving the user with something that's easy to deploy.
We will rectify the deployment issue in 1.6 by standardizing GWT around the "expanded WAR format". The two key principles are:
- The result of running the GWT compiler (and possibly some associated tools/build rules) will be an expanded WAR directory structure that can be immediately deployed to a Java Servlet Container compatible web server.
- Hosted mode will operate using essentially the same format, in the same directory, to ensure that hosted and compiled web applications behave the same.
In 1.6, we always dump all resources directly into the WAR directory, which the server serves directly out of. We automate in hosted mode what a build process would do. This is triggered by the Hosted Browser actually executing a selection script; the selection script (when running hosted mode) forces a hosted mode link. Subsequent GWT.create() calls may cause incremental links.