Differences

This shows you the differences between two versions of the page.

--- jvx:server:lco:call_events [2018/12/03 15:20]
admin
+++ jvx:server:lco:call_events [2020/07/08 17:51] (current)
cduncan articles
@@ Line 1: / Line 1: @@
 ~~NOTRANS~~
-~~Title: Server-Side Call events~~
+~~Title: Server-Side Call Events~~
-If you call a server-side function or an action, usually you don't need more than the result on the client (= UI). If you have complex business logic on server-side or if you call multiple server-side functions or actions in one single call, it would be useful to have server-side events with call information. And sometimes it's really helpful to do something after a single or all calls, e.g. cleanup of states, commit or rollback connection(s) (if you don't use autocommit).
+If you call a server-side function or an action, usually you don't need more than the result on the client (UI). If you have complex business logic on server side, or if you call multiple server-side functions or actions in one single call, it would be useful to have server-side events with call information. Sometimes it's really helpful to do something after a single or all calls, e.g., cleanup of states, commit, or rollback connection(s) (if you don't use autocommit).
-Our JVx server implementation has some events which could be useful for your application. We've defined the interface javax.rad.server.ICallHandler with following methods:
+Our JVx server implementation has some events which could be useful for your application. We've defined the interface javax.rad.server.ICallHandler with the following methods:
 <file java>
@@ Line 30: / Line 30: @@
 </file>
-The difference is that ServerContext always returns the call handler for the Master session and SessionContext returns the call handler for the current session.
+The difference is that ServerContext always returns the call handler for the master session and SessionContext returns the call handler for the current session.
 If you register listeners for the ICallHandler of MasterSession, they will be notified about all calls in your application. All other sessions will be notified about own calls.
-The events are one feature of ICallHandler. The other feature are one-time method calls via invoke... methods. The concept is similar to invokeLater of GUI toolkits like swing or JavaFX: Execute "something" after all other methods were called. On server-side it's not good to name a method invokeLater because there are different options, e.g. invoke after current call (invokeAfterCall) or invoke after all calls (invokeAfterLastCall).
+The events are one feature of ICallHandler. The other feature are one-time method calls via invoke... methods. The concept is similar to invokeLater of GUI toolkits like swing or JavaFX: Execute "something" after all other methods were called. On server-side it's not good to name a method invokeLater because there are different options, e.g., invoke after current call (invokeAfterCall) or invoke after all calls (invokeAfterLastCall).
 We have an additional method that invokes "something" after all other operations. It's invokeFinally.
-The call stack could look like following, for a single action call:
+The call stack could look like the following, for a single action call:
 <file java>
@@ Line 76: / Line 76: @@
 </file>
-== Listener registration ==
+== Listener Registration ==
-You should register your listeners in a method, annotated with @PostConstruct:
+You should register your listeners in a method annotated with @PostConstruct:
 <file java>
@@ Line 93: / Line 93: @@
 </file>
-Sure, it would be possible to register listeners in constructor of your life-cycle object, but you should know that the constructor could be called unexpected, e.g. if you inherit one LCO from another one:
+Sure, it would be possible to register listeners in constructor of your life cycle object, but you should know that the constructor could be called unexpectedly, e.g., if you inherit one LCO from another one:
 <file script>
@@ Line 102: / Line 102: @@
 </file>
-If you're using LockedScreen, the constructors of Screen, Session and Application will be called. You could check the class:
+If you're using LockedScreen, the constructors of Screen, Session, and Application will be called. You could check the class:
 <file java>
@@ Line 113: / Line 113: @@
 but it's better to use @PostConstruct.
-== Unregister listeners ==
+== Unregister Listeners ==
 Usually, it's not necessary to unregister listeners because the ICallHandler will be available as long as the session is alive. But if you're working with ServerContext, it's a good idea to remove your listeners because JVx doesn't do this automatically.
@@ Line 129: / Line 129: @@
 </file>
-== Invoke... methods or listener registration ==
+== Invoke Methods or Listener Registration ==
-It's not always possible to register a listener or you won't do this because you don't need it for all your server-calls. If you want to call a one-time function, please use invokeAfterCall or invokeAfterLastCall. Be careful with invokeFinally because this method was "reserved" for JVx objects.
+It's not always possible to register a listener, or you won't do this because you don't need it for all your server calls. If you want to call a one-time function, please use invokeAfterCall or invokeAfterLastCall. Be careful with invokeFinally because this method was "reserved" for JVx objects.