Revision: 10319
Author: [email protected]
Date: Fri Jun 10 14:37:27 2011
Log: Edited wiki page RequestFactory_2_4 through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=10319
Modified:
/wiki/RequestFactory_2_4.wiki
=======================================
--- /wiki/RequestFactory_2_4.wiki Fri Jun 10 14:24:57 2011
+++ /wiki/RequestFactory_2_4.wiki Fri Jun 10 14:37:27 2011
@@ -2,7 +2,7 @@
= !RequestFactory changes in GWT 2.4 =
-[http://code.google.com/p/google-web-toolkit/issues/list?can=2&q=Milestone%3D2_4+requestfactory&colspec=ID+Type+Status+Owner+Milestone+Summary+Stars&cells=tiles
Issue
tracker search]
+[http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=requestfactory%20Milestone=2_4&sort=id&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars%20Releasenote
Issue
tracker search]
<wiki:toc />
@@ -20,56 +20,34 @@
== Polymorphism support ==
-A proxy type will be available on the client:
- * Referenced from a RequestContext as a Request parameter or return type.
+A proxy type will be available on the client if it is:
+ * Referenced from a `RequestContext` as a `Request` parameter or return
type.
* Referenced from a referenced proxy.
- * Supertypes of referenced proxies that are proxies (i.e. assignable to
EntityProxy or ValueProxy and has an @ProxyFor(Name) annotation).
- * Referenced via an @ExtraTypes annotation placed on the RequestFactory,
RequestContext, or a referenced proxy.
- * Adding an @ExtraTypes annotation on the RequestFactory or
RequestContext allows you to add subtypes to "some else's" proxy types.
+ * A supertype of a referenced proxy that is also a proxy (i.e.
assignable to `EntityProxy` or `ValueProxy` and has an `@ProxyFor(Name)`
annotation).
+ * Referenced via an `@ExtraTypes` annotation placed on the
RequestFactory, `RequestContext`, or a referenced proxy.
+ * Adding an `@ExtraTypes` annotation on the RequestFactory or
`RequestContext` allows you to add subtypes to "some else's" proxy types.
Type-mapping rules:
* All properties defined in a proxy type or inherited from
super-interfaces must be available on the domain type.
* This allows a proxy interface to extend a "mix-in" interface.
- * All proxies must map to a single domain type via a @ProxyFor(Name)
annotation.
- * The @ProxyFor of the proxy instance is used to determine which
concrete type on the server to instantiate.
- * Any supertypes of a proxy interface that are assignable to EntityProxy
or ValueProxy and have an @ProxyFor(Name) annotation must be valid proxies.
- * Given BProxy extends AProxy: if only BProxy is referenced (e.g. via
@ExtraTypes), it is still permissable to create an AProxy.
+ * All proxies must map to a single domain type via a `@ProxyFor(Name)`
annotation.
+ * The `@ProxyFor` of the proxy instance is used to determine which
concrete type on the server to instantiate.
+ * Any supertypes of a proxy interface that are assignable to
`EntityProxy` or `ValueProxy` and have an `@ProxyFor(Name)` annotation must
be valid proxies.
+ * Given `BProxy extends AProxy`: if only `BProxy` is referenced (e.g.
via `@ExtraTypes`), it is still permissible to create an `AProxy`.
* Type relationships between proxy interfaces do not require any
particular type relationship between the mapped domain types.
- * Given BProxy extends AProxy: it is allowable for BEntity not to be a
subclass of AEntity.
+ * Given `BProxy extends AProxy`: it is allowable for `BEntity` not to
be a subclass of `AEntity`.
* This allows for duck-type-mapping of domain objects to proxy
interfaces.
* To return a domain object via a proxy interface, the declared proxy
return type must map to a domain type assignable to the returned domain
object.
* The specific returned proxy type will be the most-derived type
assignable to the declared proxy type that also maps to the returned domain
type or one of its supertypes.
== !RequestFactorySource and Annotation Processing ==
-Users 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.
-
-Users can confirm that the annotation processor is installed by
-looking for a META-INF/requestFactory/typeTokens file to be generated
-in the compiler's output directory. This file must be packaged into
-the jar file that contains the compiled proxy classes.
-
-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.
+Users 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`.
+
+Users can confirm that the annotation processor is installed by looking
for a `META-INF/requestFactory/typeTokens` file to be generated in the
compiler's output directory. This file must be packaged into the jar file
that contains the compiled proxy classes.
+
+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.
== !ServiceLayer changes ==
-Several 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.
+Several 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.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
