Type: Feature Request
Status: Closed (View Workflow)
Affects Version/s: None
Fix Version/s: None
Similar Issues:Show 10 results
ERRAI-392 Conversational RPC ERRAI-360 asynchronous handling of RPC requests on server-side ERRAI-203 Support creation of RPC proxies on the server ERRAI-157 Provide a mechanism to access the HTTP request and session objects from RPC endpoints ERRAI-842 Conversational event in rpc context ERRAI-129 Errai-CDI seam-solder and RPC services ERRAI-207 Built-in subscription for RPC services cannot be used to receive plain (non-RPC) messages ERRAI-666 RPC error reporting does not display additional details sent from server ERRAI-559 Improvement of RPC / Marshaller performance ERRAI-337 2 @Service instances are created when using Errai RPC and plain (non-RPC) messages instead of adding the new subscription to the existing instance
One of the nice features of the RequestFactory framework is to chain requests together before sending them to the server. The use cases for this type of requirement are numerous. For example, a "page" can be provided modules which are each responsible for loading their own component. A Single request can be passed into the module and the module can append its service calls. The entire request is either passed/failed together.
- Keeps the Service API clean and simple, rather than creating specific methods/response beans to handle the loading requirements for a particular page view.
- Moves Errai further along towards erasing the line between client and server (I believe). This is a more natural way of programming, and makes the asynchronous nature less of a burden
- Create specific method calls for complex loading requirements OR
- chain the requests, with each subsequent request only occurring once the first one is finished. This is more unnatural for the developer.
I've put together a sample, which is purely for informational purposes of how something like this could look: