Linked Java Object Builder

Linked Java Object Builder

In this topic ...

Quick Tips
Specifying Inputs
Calling Other Methods and Model Actions from an LJO
Related Topics ...

Overview: Working with Java
Overview: Working with XML
Overview: Handling Errors
Passing Arguments to Actions
WebSphere Portlet Factory API Documentation

The Linked Java Object builder adds the public methods of a Java class to the Web application. We can use the Linked Java Object builder to incorporate existing Java code or we can create new Java classes to be used with Linked Java Object builder calls to consolidate commonly used methods into a single, re-used Java class.

Quick Tips

Provide your methods with access to the current webAppAccess object -- We can provide the methods in your LJOs with access to the current webAppAccess object by declaring that those methods take at least one argument of type WebAppAccess. For example,

public IXml getCustomers(WebAppAccess myWebApp) {...}
Do not store the WebAppAccess object as a member variable as it can become stale, due to the fact that LJOs remain instantiated throughout the execution of the Web application.

Simplifying Linked Java Object Method Calls -- Set the Model Method Base input to "Use this Linked Java Object's class as a base for all methods in model".

Using this naming convention allows you to call methods in the Linked Java Object with "webAppAccess.callMethod("MethodName");" instead of "webAppAccess.callMethod("LJOName.MethodName");."

Persisting Linked Java Objects during failover -- LJOs persist during a failover event as long as the underlying Java class implements the Serializable interface.
Avoid overloading methods in Linked Java Objects -- If you are creating Java source files to be used as Linked Java Objects, create unique methods instead of overloading one method. Doing so ensures predictable behavior and makes choosing those methods easier when using the Data picker or various select boxes for assigning actions to controls.

If we need to use overloaded methods in your Linked Java Object, try to write them all before you add the Linked Java Object to your model. This is so builder calls don't get "confused" about which method to call. If you do need to overload methods after adding the Linked Java Object to your model, be sure to go into each builder call that calls a variation of the overloaded method and confirm that it is calling the appropriate one.

Specifying Inputs

The Linked Java Object builder takes the inputs described in the table below. For help on inputs common to many or all builders such as those in the Properties and HTML Attributes input groups, see "Using the Builder Call Editor."

Input Name Description
Name Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Class Name Enter the fully-qualified name for the class that you want to use for your LJO. For example,

com.acme.BigRock
mypackage.MyClass

If there is no package (the class is either in the Factory's WEB-INF/classes or work/classes directory), you just enter the class name.
Advanced
Instantiation Method Select a method that calls a constructor in your Java class and passes any necessary arguments.
State and Failover Select the failover behavior for the LJO.
You can choose from the following values:
Read-Write - This setting prompts the model to save the current value for the Variable in the case of a failover event. This failover functionality does incur a small performance hit, so only use the Default setting when necessary.
Read-Write but not persisted for failover - This setting allows your Variable's value to change, but its value at the time of failover will not be preserved.
Read-only: shared across all users - This setting makes your variable behave like a constant. Its value will never change from the initial setting. As a result, some performance gains are realized because a copy of the Variable is not made during generation and the Variable is not processed during the failover event.
Request Scope - This setting will store the variable value in a request attribute rather than in a class (WebAppInstanceData). Doing this can improve performance for large variables that are set and read within a single request, and not needed across multiple requests.
Do not use Request Scope for items such as XML variables that are used in multiple requests. Doing so would clone and initialize the request copy of that variable for every use. Use Request Scope for infrequently used variables and variables that hold large objects or hierarchies of objects (such as XML). A typical use of request scope might be for a variable that contains data for a table that is displayed on only page of a multi-page application.
Model Method Base Select whether or not you want the class generated for the model's Method builder calls to extend the class specified for this LJO.
Choose either of these values:

Use this Linked Java Object's class as a base for all methods in model -- Select this value to define the generated class for the model method as extending the class specified for this LJO. Doing so provides the following benefits:

       - Methods in the LJO get displayed as "top-level"
methods in the Reference Chooser.
       - Calling methods in the LJO from other methods
is a little simpler. For example,
   webAppAccess.callMethod("MethodName");
          instead of:
   webAppAccess.callMethod("LJOName.MethodName");

Don't extend model methods from this Linked Java Object class -- Select this value if it does not make sense to extend the LJO class for the model methods. One case would be when the LJO contains many member variables.

Overwriting
Rename Existing This input is useful in cases where you want to change the behavior of code that was placed in the WebApp by a high-level builder or by an Imported Model.
For example, you might want to do this if you have a Domino View & Form builder in your model, and you want to use a different class for one of the LJO's that Builder adds to the WebApp. The Domino View and Form Builder does not provide an "LJO Class Name" input. But, we can place a new LJO Builder in the model and give it the same name as that assigned by the Domino View and From Builder, thus replacing the existing LJO and specifying new class.

Enable - When checked, this input will cause the Builder to replace an existing WebApp object with a new object. The Builder will locate the existing WebApp object (variable, LJO, etc.), rename it, and then create a replacement object.

This input is available on the following low-level Builders that create WebApp objects: Action List, Imported Page, Linked Java Object, Linked Model, Method, Method Call, Page, Variable and Schema.

Calling Other Methods and Model Actions from an LJO

Use the following syntax examples to call other methods or actions in a model:

Call methods added by Method builder calls: webAppAccess.callMethod("MethodBuilderName");
Call methods added by an LJO: webAppAccess.callMethod("LJOName.methodName", arg1, ...);
Call methods in a Linked Model: webAppAccess.callMethod("LinkedModelName.MethodBuilderName");

Call methods on an LJO in a Linked Model: webAppAccess.callMethod("LinkedModelName.LJOName.methodName", arg1, ...);

Input Name	Description
Name	Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Class Name	Enter the fully-qualified name for the class that you want to use for your LJO. For example, com.acme.BigRock mypackage.MyClass If there is no package (the class is either in the Factory's WEB-INF/classes or work/classes directory), you just enter the class name.
Advanced
Instantiation Method	Select a method that calls a constructor in your Java class and passes any necessary arguments.
State and Failover	Select the failover behavior for the LJO. You can choose from the following values: Read-Write - This setting prompts the model to save the current value for the Variable in the case of a failover event. This failover functionality does incur a small performance hit, so only use the Default setting when necessary. Read-Write but not persisted for failover - This setting allows your Variable's value to change, but its value at the time of failover will not be preserved. Read-only: shared across all users - This setting makes your variable behave like a constant. Its value will never change from the initial setting. As a result, some performance gains are realized because a copy of the Variable is not made during generation and the Variable is not processed during the failover event. Request Scope - This setting will store the variable value in a request attribute rather than in a class (WebAppInstanceData). Doing this can improve performance for large variables that are set and read within a single request, and not needed across multiple requests. Do not use Request Scope for items such as XML variables that are used in multiple requests. Doing so would clone and initialize the request copy of that variable for every use. Use Request Scope for infrequently used variables and variables that hold large objects or hierarchies of objects (such as XML). A typical use of request scope might be for a variable that contains data for a table that is displayed on only page of a multi-page application.
Model Method Base	Select whether or not you want the class generated for the model's Method builder calls to extend the class specified for this LJO. Choose either of these values: Use this Linked Java Object's class as a base for all methods in model -- Select this value to define the generated class for the model method as extending the class specified for this LJO. Doing so provides the following benefits: - Methods in the LJO get displayed as "top-level" methods in the Reference Chooser. - Calling methods in the LJO from other methods is a little simpler. For example, webAppAccess.callMethod("MethodName"); instead of: webAppAccess.callMethod("LJOName.MethodName"); Don't extend model methods from this Linked Java Object class -- Select this value if it does not make sense to extend the LJO class for the model methods. One case would be when the LJO contains many member variables.
Overwriting
Rename Existing	This input is useful in cases where you want to change the behavior of code that was placed in the WebApp by a high-level builder or by an Imported Model. For example, you might want to do this if you have a Domino View & Form builder in your model, and you want to use a different class for one of the LJO's that Builder adds to the WebApp. The Domino View and Form Builder does not provide an "LJO Class Name" input. But, we can place a new LJO Builder in the model and give it the same name as that assigned by the Domino View and From Builder, thus replacing the existing LJO and specifying new class. Enable - When checked, this input will cause the Builder to replace an existing WebApp object with a new object. The Builder will locate the existing WebApp object (variable, LJO, etc.), rename it, and then create a replacement object. This input is available on the following low-level Builders that create WebApp objects: Action List, Imported Page, Linked Java Object, Linked Model, Method, Method Call, Page, Variable and Schema.