Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
jvx:server:lco:actions [2020/06/15 10:49] cduncan Edited for English grammar (capitalization, punctuation, correct verb conjugation) |
jvx:server:lco:actions [2020/07/08 17:51] cduncan articles |
||
---|---|---|---|
Line 2: | Line 2: | ||
~~Title: Working With Server-Side Actions~~ | ~~Title: Working With Server-Side Actions~~ | ||
- | A [[jvx:communication:calling_server_action|server-side action]] is a simple Java method defined in a [[jvx:server:lco:lifecycle|life cycle object]] (= LCO). A standard JVx application has an application global LCO, a session LCO, and a LCO for every screen. | + | A [[jvx:communication:calling_server_action|server-side action]] is a simple Java method defined in a [[jvx:server:lco:lifecycle|life cycle object]] (LCO). A standard JVx application has an application global LCO, a session LCO, and a LCO for every screen. |
An action can be defined in every LCO, but it makes sense to define the actions in the right "context" and for the right "scope". But what is the right scope? | An action can be defined in every LCO, but it makes sense to define the actions in the right "context" and for the right "scope". But what is the right scope? | ||
- | Start defining your actions in screen LCOs and if an action is reusable, move it to the session LCO. The application LCO is not a relevant context for actions because it makes no difference if you define an action in the application LCO or session LCO. The application LCO exists exactly once for an application. The session LCO will be created for every master connection (= user login). The application LCO can be used to store "application global" objects or states. | + | Start defining your actions in screen LCOs and if an action is reusable, move it to the session LCO. The application LCO is not a relevant context for actions because it makes no difference if you define an action in the application LCO or session LCO. The application LCO exists exactly once for an application. The session LCO will be created for every master connection (user login). The application LCO can be used to store "application global" objects or states. |
- | The general rule is that the screen LCO should be the first place for your actions, and the session LCO should be used for reusable actions. But be careful because there are some things to know! | + | The general rule is that the screen LCO should be the first place for your actions, and the session LCO should be used for reusable actions. However, be careful because there are some things to know! |
- | You application usually has following classes: | + | You application usually has the following classes: |
<file java> | <file java> | ||
Line 29: | Line 29: | ||
</file> | </file> | ||
- | The Students LCO extends the Session LCO and the Session LCO extends the Application LCO. This class hierarchy makes it possible to call actions from the super class, e.g., | + | The Students LCO extends the Session LCO, and the Session LCO extends the Application LCO. This class hierarchy makes it possible to call actions from the super class, e.g., |
<file java Session.java> | <file java Session.java> | ||
Line 81: | Line 81: | ||
All objects in the Application LCO exist only once - like singletons per application. All objects in the Session LCO exist only once per user. All objects in the Screen LCOs, like Students, exist for every screen instance. | All objects in the Application LCO exist only once - like singletons per application. All objects in the Session LCO exist only once per user. All objects in the Screen LCOs, like Students, exist for every screen instance. | ||
- | If you close a screen, all Screen LCO instances will be discarded and if you logout from the application, all Session LCO instances will be discarded. This mechanism helps to reduce the memory consumption but it adds complexity to your LCOs. | + | If you close a screen, all Screen LCO instances will be discarded, and if you logout from the application, all Session LCO instances will be discarded. This mechanism helps to reduce the memory consumption but it adds complexity to your LCOs. |
- | The Students LCO extends the Session LCO and all public/protected/package private methods of the Session LCO are available in the Students LCO. But if you access an object like contacts via getContacts, you will get the instance from the Session LCO and not a new instance from the Students LCO. If you overwrite the method in the Students LCO, you will receive a new instance of the object for your LCO and not the instance from the Session LCO. This is a built-in security mechanism and a sort of object scope. | + | The Students LCO extends the Session LCO and all public/protected/package private methods of the Session LCO are available in the Students LCO. However, if you access an object like contacts via getContacts, you will get the instance from the Session LCO and not a new instance from the Students LCO. If you overwrite the method in the Students LCO, you will receive a new instance of the object for your LCO and not the instance from the Session LCO. This is a built-in security mechanism and a sort of object scope. |
The only thing you should really know is that a call or an object access will use the LCO where the method was declared. | The only thing you should really know is that a call or an object access will use the LCO where the method was declared. | ||
- | In most cases, the standard mechanism works like a charm, but sometimes you need more control. Imagine you have 3 screens and every screen has the same actions. You would define all actions in the Session LCO because they are re-usable. But all actions are stateful and save a timestamp in a field property: | + | In most cases, the standard mechanism works like a charm, but sometimes you need more control. Imagine you have three screens and every screen has the same actions. You would define all actions in the Session LCO because they are reusable. But all actions are stateful and save a timestamp in a field property: |
<file java> | <file java> | ||
Line 129: | Line 129: | ||
</file> | </file> | ||
- | If you call the openAccount action via Students LCO, the Session LCO will be used, and the date field will be saved in Session LCO. If you call the same action via Teacher LCO, the Session LCO will be used, and the same date field will be used. This is not good because the Screen LCOs are not independent from each other! | + | If you call the openAccount action via Students LCO, the Session LCO will be used, and the date field will be saved in Session LCO. If you call the same action via Teacher LCO, the Session LCO will be used, and the same date field will be used. This is not good because the Screen LCOs are not independent of each other! |
One possible solution could be that you move all reusable screen actions to a placeholder class: | One possible solution could be that you move all reusable screen actions to a placeholder class: | ||
Line 175: | Line 175: | ||
If you call the openAccount action, the date field will be saved in Students or Teacher LCO, because the placeholder class is not the Session LCO, and everything will work as expected. The Screen LCOs are independent from each other. | If you call the openAccount action, the date field will be saved in Students or Teacher LCO, because the placeholder class is not the Session LCO, and everything will work as expected. The Screen LCOs are independent from each other. | ||
- | This solution needs an extra class to work-around the built-in call mechanism of JVx. But there's a built-in solution without placeholder class: | + | This solution needs an extra class to work around the built-in call mechanism of JVx. But there's a built-in solution without placeholder class: |
<file java> | <file java> |