|
RequestFactory_2_4
A summary of RequestFactory changes in GWT 2.4
RequestFactory changes in GWT 2.4Overview
Polymorphism supportA proxy type will be available on the client if it is:
Type-mapping rules:
RequestFactorySource and Annotation ProcessingUsers who depend on RequestFactorySource must now compile their proxy interfaces with the RequestFactory annotation processor. This tool is bundled in the requestfactory-client.jar or available separately in requestfactory-apt.jar. For Java 6 users, javac will automatically detect the annotation processor. Eclipse users will need to enable annotation processing via <Project properties> --> Java Compiler --> Annotation Processing and add requestfactory-apt.jar to the list of jars in Java Compiler --> Annotation Processing --> Factory Path. Additionally, the -Averbose=true flag can be passed to javac (or specified in the Annotation Processing configuration UI) to enable diagnostic output for the annotation processor. More information can be found on the RequestFactoryInterfaceValidation wiki page. ServiceLayer changesSeveral of the ServiceLayer.resolveX() method signatures have changed in this release. These changes were made in order to allow the use of obfuscated type and operation tokens to reduce payload and generated JS size and to allow the use of overloaded method names in RequestContext subtypes. Users who have written their own ServiceLayerDecorator subclasses that override any of the resolveX() methods will need to modify their code to conform to the new API. In general, the expected behavior of the resolveX() methods is unchanged. Users who need to retain compatibility with 2.3 and 2.4 RequestFactory server code can leave methods with the old signatures in place, removing any @Override annotations. Improved request batchingPrior to GWT 2.4, it was only possible to chain Request instances that originated within a single RequestContext. GWT 2.4 adds a RequestContext.append() method, which allows cross-context chaining. interface ContextA extends RequestContext {
Request<Boolean> requestA();
}
interface ContextB extends RequestContext {
Request<Integer> requestB();
}
interface MyRequestFactory extends RequestFactory {
ContextA ctxA();
ContextB ctxB();
}
class Caller {
MyRequestFactory factory;
void doSomething() {
ContextA ctxA = factory.ctxA();
ctxA.requestA().to(new Receiver<Boolean>(){});
ContextB ctxB = ctxA.append(factory.ctxB());
// ctxA is still completely usable after calling append()
ctxB.requestB().to(new Receiver<Integer>(){});
ctxA.fire(); // ctxB.fire() would be equivalent
}
}Any RequestContext may have another newly-created RequestContext appended to it. Once two RequestContext instances are joined, they may be used independently of one another until fire() is called on any of the RequestContext instances. Building on top of the append() facility is the utility class RequestBatcher which makes it easy to combine all Requests made during one tick of the event loop into a single HTTP request. A RequestBatcher vends an instance of a RequestContext and automatically calls fire() on it before the JavaScript execution returns to the browser (via Scheduler.scheduleFinally()). The public fire() methods on the returned RequestContext and its Request objects will not trigger an HTTP request, although any Receiver provided will still be enqueued, allowing the RequestContext vended by a RequestBatcher to be used with existing code. public class MyRequestBatcher extends RequestBatcher<MyRequestFactory, MyRequestContext> {
// Could be provided to consumers via DI instead
public static final MyRequestBatcher INSTANCE = new MyRequestBatcher();
public MyRequestBatcher() {
// MyRequestFactory could also be injected
super(GWT.create(MyRequestFactory.class));
}
@Override
protected MyRequestContext createContext(MyRequestFactory factory) {
return factory.myRequestContext();
}
// Provide batched getter for an additional RequestContext type
public OtherRequestContext otherRequestContext() {
return get().append(getRequestFactory().otherRequestContext());
}
}public void respondToUserAction() {
MyRequestContext ctx = MyRequestBatcher.INSTANCE.get();
ctx.doUsualThings();
// Calling fire() would be a no-op, although fire(Receiver<Void>) will enqueue the callback
}
|
► Sign in to add a comment
Is there any example on how one would use the new RequestBatcher? to batch multiples operation from diffent type of RequestContext??
@mana...@gurumades.com, that's what append() is for.
I don't even have an Java Compiler --> Annotation Processing to start with in my eclipse Preferences, why? My requestFactory demo: http://demogwtrequestfactory.appspot.com
issue6193 is not shown above as closed, there is a typo on the memory leak listing.
What about a method to remove a previusly appended request? Thank you