Entity Proxies
Group items matching
in title, tags, annotations or url
151More
Getting Started with RequestFactory - Google Web Toolkit - Google Code - 0 views
-
-
-
proxy types
-
entity types
- ...147 more annotations...
-
methods that return service stubs
-
one RequestFactory interface for your application
-
employeeRequest();
-
@Service(Employee.class)
-
extends RequestContext
-
extends RequestFactory
-
service stub
-
RequestFactory service stubs
-
must extend RequestContext
-
The methods in a service stub do not return entities directly
-
return subclasses of com.google.gwt.requestfactory.shared.Request.
-
This allows the methods on the interface to be invoked asynchronously with
-
Request.fire()
-
fire( new Receiver()
-
onSuccess
-
callers pass an AsyncCallback that implements onSuccess()
-
takes a Receiver which must implement onSuccess()
-
Receiver is an abstract class having a default implementation of onFailure()
-
you can extend Receiver and override onFailure()
-
onViolation()
-
any constraint violations on the server
-
The Request type returned from each method
-
parameterized with the return type of the service method.
-
Methods that have no return value should return type Request<Void>
-
BigDecimal, BigInteger, Boolean, Byte, Enum, Character, Date, Double, Float, Integer, Long, Short, String, Void
-
subclass of EntityProxy
-
List<T> or Set<T>
-
primitive types are not supported
-
methods that operate on an entity itself
-
like persist() and remove()
-
return objects of type InstanceRequest rather than Reques
-
Server Implementations
-
methods defined in an
-
entity's service interface
-
implemented in the class named
-
@Service annotation
-
in these examples, is the entity class
-
service implementations do not directly implement the RequestContext interface
-
server-side implementations use the domain entity types
-
@Entity
-
EntityManager
-
createQuery
-
getResultList();
-
entityManager()
-
createEntityManager()
-
em.persist(this);
-
em.remove(attached
-
em.close();
-
defined in the service's
-
RequestContext interface
-
even though the implementation does not formally implement the interface in Java
-
name and argument list for each method
-
same on client and server
-
Client side methods
-
return Request<T>
-
only T on the server
-
EntityProxy types become the domain entity type on the server
-
Methods that return a Request object in the client interface are implemented as static methods on the entity
-
Methods that operate on a single instance of an entity, like persist() and remove(),
-
eturn an
-
InstanceRequest
-
in the client interface
-
Instance methods do not pass the instance directly, but rather via the
-
using()
-
instance methods must be implemented as non-static methods in the entity type
-
Four special methods are required on all entities
-
as they are used by the RequestFactory servlet:
-
constructor
-
findEntity
-
An entity's getId()
-
is typically auto-generated by the persistence engine (JDO, JPA, Objectify, etc.)
-
"find by ID" method has a special naming convention
-
find()
-
"find" plus the type's simple name
-
On the server
-
getVersion() method is used by RequestFactory to infer if an entity has changed
-
backing store (JDO, JPA, etc.) is responsible for updating the version each time the object is persisted,
-
RequestFactoryServlet sends an UPDATE
-
if an entity changes as
-
Second, the client maintains a version cache of recently seen entities
-
Whenever it sees an entity whose version has changed, it fires
-
UPDATE events on the event bus
-
so that listeners can update the view
-
GWT.create
-
and initialize it with your application's EventBus
-
GWT.create
-
requestFactory.initialize
-
create a new entity on the client
-
EmployeeRequest request
-
EmployeeProxy newEmployee
-
All client-side code should use the EmployeeProxy
-
not the Employee entity itself
-
unlike GWT-RPC, where the same concrete type is used on both client and server
-
RequestFactory
-
designed to be used with an ORM layer like JDO or JPA
-
on the server
-
to build data-oriented (CRUD) apps with an ORM-like interface
-
on the client
-
easy to implement a data access layer
-
structure your server-side code in a data-centric way
-
GWT-RPC, which is service-oriented
-
On the client side, RequestFactory keeps track of objects that have been modified and sends only changes
-
lightweight network payloads
-
solid foundation for automatic batching and caching of requests in the future
-
RequestFactoryServlet
-
RequestFactory uses its own servlet
-
own protocol
-
not designed for general purpose services like GWT-RPC
-
implements its
-
It is designed specifically for implementing a persistence layer on both client and server.
-
In persistence frameworks like JDO and JPA, entities are annotated with
-
client-side representation of an entity
-
known as a
-
DTO (Data Transfer Object)
-
hook used to indicate that an object can be managed by RequestFactory
-
RequestFactory
-
EntityProxy interface
-
automatically populates bean-style properties between entities on the server and the corresponding EntityProxy on the client,
-
send only changes ("deltas") to the server
-
extends EntityProxy
-
interface
-
@ProxyFor
-
reference the server-side entity being represented
-
It is not necessary to represent every property and method from the server-side entity in the EntityProxy
-
EntityProxyId returned by this method is used throughout RequestFactory-related classes
-
while getId() is shown in this example, most client code will want to refer to
-
EntityProxy.stableId() i
-
to represent any type
-
is not required to expose an ID and version
-
often used to represent embedded object types within entities
-
@Embedded
-
Address
-
Address type
-
POJO with no persistence annotations
-
Address is represented as a ValueProxy
-
extends ValueProxy
-
interface
-
extends EntityProxy
-
interface
-
AddressProxy
-
AddressProxy
-
ValueProxy can be used to pass any type to and from the server
-
RequestFactory
-
interface between your client and server code
-
RequestContext interface
-
The server-side service
-
must implement each method
125More
Organize Projects - Google Web Toolkit - Google Code - 0 views
-
com.google.gwt.gears.Gears
-
-
two ways to approach loading them
-
nclude each module with a separate <script> tag
- ...118 more annotations...
-
Create a top level module XML definition
-
Compile the top level module
-
the second approach will lead to much better end-user performance
-
each module has to be downloaded separately by the end-user's browser
-
each module will contain redundant copies of GWT library
-
conflict with each other during event handling
-
Linkers are divided into three categories, PRE, POST, and PRIMARY
-
one primary linker is run for a compilation
-
everal linkers are provided by Core.gwt.xml, which is automatically inherited by User.gwt.xml.
-
monolithic JavaScript file.
-
cross-site deployment model.
-
standard iframe-based
-
<add-linker name="xs" />
-
The GWT compiler
-
packaging its output with the Linker subsystem
-
responsible for the final packaging of the JavaScript code
-
providing a pluggable bootstrap mechanism
-
re-use an existing Java API for a GWT project,
-
<super-source>
-
"re-root" a source path
-
to emulate part of the JRE not implemented by GWT
-
tells the compiler to add all subfolders of com/example/myproject/jre/
-
to the source path
-
com/google/myproject/gwt/jre/java/util/UUID.java
-
most commonly used elements in the module XML file.
-
<inherits name="
-
herits all the settings from the specified module
-
<entry-point class=
-
Entry points are all compiled into a single codebase
-
when the onModuleLoad() of your first entry point finishes, the next entry point is called immediately.
-
Any number of entry-point classes can be added
-
<source path="
-
resources get copied into the output directory during a GWT compile.
-
client subpackage is implicitly added to the source path
-
<public path="path" />
-
treated as a publicly-accessible resource.
-
resources get copied into the output directory
-
the public subpackage is implicitly added to the public
-
<servlet
-
For RPC, this element loads a servlet class
-
mounted at the specified URL path
-
path=
-
-
class="
-
-
URL path should be absolute
-
@RemoteServiceRelativePath attribute
-
you must configure a WEB-INF/web.xml in your war directory to load any servlets needed.
-
n development mode,
-
<script src="
-
external JavaScrip
-
<stylesheet src="
-
Extends the set of values
-
for an existing client property
-
<replace-with-class>
-
<generate-with-class>
-
<when-property-is
-
three different types of predicates are
-
<when-type-assignable
-
<when-type-is
-
<all>
-
<any>
-
<none>
-
GWT libraries are organized into modules
-
you want to inherit at least the User module
-
contains all the core GWT functionality
-
including the EntryPoint class
-
widgets and panels
-
History feature
-
Internationalization
-
DOM programming, and more
-
Low-level HTTP
-
Use the following syntax to cause an external JavaScript file to be loaded
-
before your module entry point is called.
-
as if you had included it explicitly using the HTML <script
-
loaded before your onModuleLoad() is called.
-
all included scripts will be loaded when your application starts, in the order in which they are declared.
-
associate external CSS files with your module
-
GWT.getModuleBaseURL() + "foo.css" in client code
-
module's public path
-
useful when
-
inheritance makes resource inclusion particularly convenient.
-
If you wish to create a reusable library that relies upon particular stylesheets or JavaScript files, you can be sure that clients
-
see the documentation for FileSet for a general overview
-
<public>
-
<super-source>
-
<source>
-
includes
-
excludes
-
defaultexcludes
-
casesensitive
-
By default, the patterns listed here are excluded.
-
defaultexcludes is true
-
<script src='myApp/myApp.nocache.js'></script>
-
<script> tags always block evaluation of the page
-
<img> tags do not block page evaluation
-
two simultaneous connections
-
The body.onload() event will only fire once all external resources are fetched, including images and frames.
-
GWT selection script
-
like a normal script tag
-
but the compiled script will be fetched asynchronously.
-
Parsing is blocked until externalScriptZero.js is done fetching and evaluating.
-
myApp/myApp.nocache.js completes
-
the compiled scrip
-
(<hashname>.cache.html
-
begins fetching in a hidden IFRAME (this is non-blocking).
-
onModuleLoad() is not called yet, as we're still waiting on externalScriptOne.js
-
body.onload() fires
-
onload='alert("w00t!")
-
-
put the GWT selection script as early as possible
-
because it won't block any other script requests
-
<img> tags are not guaranteed to be done loading when onModuleLoad() is called
-
<script> tags are guaranteed to be done loading when onModuleLoad() is called
-
multiple EntryPoints
-
will all be called in sequence as soon as that module (and the outer document) is ready
-
multiple GWT modules within the same page
-
each module's EntryPoint will be called as soon as both that module and the outer document is ready
-
EntryPoints are not guaranteed to fire at the same time
-
or in the same order
-
in which their selection scripts were specified in the host page