Trace:
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
jvx:server:lco:objects [2018/02/01 22:21] admin created |
jvx:server:lco:objects [2020/06/26 12:16] (current) cduncan Edited for English grammar (capitalization, punctuation, correct verb conjugation) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ~~Title: Creating Lifecycle Objects~~ | + | ~~Title: Creating Life Cycle Objects~~ |
| - | JVx's [[jvx:server:lco:lifecycle|Lifecycle Objects]] are not only containers for objects and methods, they also allow the reuse of functionality through inheritance. Any POJO can potentially be used as a lifecycle object, although this would mean that we forego the advantage of reuse. | + | JVx's [[jvx:server:lco:lifecycle|Life Cycle Objects]] are not only containers for objects and methods, they also allow the reuse of functionality through inheritance. Any POJO can potentially be used as a lifecycle object, although this would mean that we forego the advantage of reuse. |
| We recommend a special use and a predefined class hierarchy to exploit all the advantages without restrictions! | We recommend a special use and a predefined class hierarchy to exploit all the advantages without restrictions! | ||
| Line 7: | Line 7: | ||
| == Configuration == | == Configuration == | ||
| - | Ideally, lifecycle objects are defined for the application and for the MasterSession. | + | Ideally, life cycle objects are defined for the application and for the MasterSession. |
| The objects are defined in the application configuration: | The objects are defined in the application configuration: | ||
| Line 29: | Line 29: | ||
| Each MasterConnection (Client) requires a MasterSession (Server) to access the server. | Each MasterConnection (Client) requires a MasterSession (Server) to access the server. | ||
| - | The lifecycle object for the application is optional and is only required for tasks spanning multiple applications. | + | The life cycle object for the application is optional and is only required for tasks spanning multiple applications. |
| == Class Hierarchy == | == Class Hierarchy == | ||
| Line 35: | Line 35: | ||
| We will explain the class hierarchy based on a showcase application. | We will explain the class hierarchy based on a showcase application. | ||
| - | The applications lifecycle object: | + | The applications life cycle object: |
| <file java Application.java> | <file java Application.java> | ||
| Line 53: | Line 53: | ||
| The class GenericBean handles the object administration, which is why we derive from it. | The class GenericBean handles the object administration, which is why we derive from it. | ||
| - | The MasterSession lifecycle object: | + | The MasterSession life cycle object: |
| <file java Session.java> | <file java Session.java> | ||
| Line 125: | Line 125: | ||
| We derive from Application to receive full access to the methods and objects of the super class. The derivation of GenericBean ensures the availability of objects. | We derive from Application to receive full access to the methods and objects of the super class. The derivation of GenericBean ensures the availability of objects. | ||
| - | Each SubConnection (Client)), and therefore each WorkScreen, receives its own lifecycle object: | + | Each SubConnection (Client), and, therefore, each workscreen, receives its own life cycle object: |
| <file java Educations.java> | <file java Educations.java> | ||
| Line 134: | Line 134: | ||
| /** | /** | ||
| - | * The <code>Educations</code> class is the life-cycle object for <code>EducationsFrame</code>. | + | * The <code>Educations</code> class is the life cycle object for <code>EducationsFrame</code>. |
| */ | */ | ||
| public class Educations extends Session | public class Educations extends Session | ||
| Line 169: | Line 169: | ||
| </file> | </file> | ||
| - | The lifecycle object is derived from Session to also receive full access to all methods and objects of the super class. | + | The life cycle object is derived from session to also receive full access to all methods and objects of the super class. |
| - | By calling getDBAccess we can asee the advantage of this technique. We open the database connection at a central location and all derivations have access to the connection. | + | By calling getDBAccess we can see the advantage of this technique. We open the database connection at a central location and all derivations have access to the connection. |
| By using this procedure we perform changes at a central location; we can save time and solve dependencies. | By using this procedure we perform changes at a central location; we can save time and solve dependencies. | ||
| Line 177: | Line 177: | ||
| == GenericBean == | == GenericBean == | ||
| - | The previous example shows that due to the derivations all methods are inherited, but that each instance would usually manage its own objects. We would therefore expect that each instance of Educations creates a new database connection through the call of getDBAccess! | + | The previous example shows that, due to the derivations, all methods are inherited but each instance would usually manage its own objects. We would, therefore, expect that each instance of Educations creates a new database connection through the call of getDBAccess! |
| This is the difference between POJO and GenericBean. | This is the difference between POJO and GenericBean. | ||
| - | Because of the derivation of GenericBean, the server makes sure that all instances are reused. In our example the session Instance is set as the parent at the instantitation of Educations and the Application instance is set as parent of the Session instance. Because of this definition, the method getDBAccess always returns the same database connection. | + | Because of the derivation of GenericBean, the server makes sure that all instances are reused. In our example, the session Instance is set as the parent at the instantiation of Educations and the Application instance is set as parent of the Session instance. Because of this definition, the method getDBAccess always returns the same database connection. |
| Another feature of GenericBean is the access to managed objects by their names: | Another feature of GenericBean is the access to managed objects by their names: | ||
| Line 189: | Line 189: | ||
| </file> | </file> | ||
| - | We can therefore call either getEducations() or get("educations") and in both cases the same instance is delivered. For this process to work the desired object has to be instatiated and put to the cache: | + | We can, therefore, call either getEducations() or get("educations") and, in both cases, the same instance is delivered. For this process to work, the desired object has to be instantiated and put to the cache: |
| <file java> | <file java> | ||
| Line 203: | Line 203: | ||
| A rather unusual, but economical, approach of the GenericBean is the initialization of objects without get methods. In this case objects are accessed via name only. | A rather unusual, but economical, approach of the GenericBean is the initialization of objects without get methods. In this case objects are accessed via name only. | ||
| - | Our Educations lifecycle object would be implemented as follows: | + | Our Educations life cycle object would be implemented as follows: |
| <file java Educations.java> | <file java Educations.java> | ||