Linked Model Builder

Linked Model Builder

In this topic ...

Quick Tips
Specifying Inputs
When to Use a Linked Model
Related Topics ...

Implementing Inter-Portlet Communications
How to Use the Shared Variable Builder
How to Use the Cooperative Portlet Target Builder
How to Use the Cooperative Portlet Source Builder

Linked models are the primary unit of modularity for an application. They are roughly analogous to classes in Java. They contain methods and state data, and support the distinction between public and private access. From a host or "container" model , we can directly access any public methods, Linked Java Objects (LJOs), action lists, and pages in a linked model.

Quick Tips

Set the Instance Rule input appropriately -- If each session does not need its own instance of a linked model, you can enhance the performance of your Web application by setting the Instance Rule input to: Always use same instance and state data for a session.

Specifying Inputs

The Linked Model 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.
Model Use the Model Chooser to select the model that the current model will link to.
Instance Rule Determines whether the Factory servlet generates an instance of the linked model for each request in the session or if it reuses the instance it generates for the first request.
Set the value of this input to:
Create new instance and state data for a session -- Sets the Factory servlet to generate a new instance for each request in the session.
Always use same instance and state data for a session -- Sets the Factory servlet to use the instance of the model generated by the first request in the session for all subsequent requests.
Note that This feature does not operate in the Portal environment because portlet models in that environment each have their own session. If we need to share data between portlets in the same WAR, use the Shared Variable Builder. If we need to share data between portlets in different WARs, use explicit portlet-to-portlet communication mechanisms provided by the portlet container, such as portlet wiring.
Advanced
Inherit Explicit Profile Enable this checkbox if you want the profiled builder call inputs in the linked model to get their values from the profile passed explicitly as part of the request for the host model.
The model's normal profile selection will not take place if you choose to inherit explicit profiles. All profiled inputs will get their values from the profile passed to the host model.
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.

When to Use a Linked Model

Linked models are the ideal approach to follow in several common application scenarios. Some of these scenarios include:

Modularity of large applications - Using linked models provides you with all the advantages of modular coding, including code reuse and better system organization.
For top-down skeleton modeling - We can create a model that contains all of your application's schemas, commonly used methods, etc. We can then link into this skeleton model from other models in the application. Now the other models can reference and access the commonly used structural entities you have placed in the linked model.
For complete interactive pages and associated code - We can implement a "User registration" model which has a set of pages for entering and editing user data. This model might be called from one or more application models whenever a new user goes to a Web site. The main application would set event handlers in the New User Registration model for "Done" and "Cancel", and then call it to start the registration process.

This process might extend over a number of pages and interactions. When registration is complete, the New User Registration model would fire the "Done" event, and the main model would proceed to its next page.

For parts of pages and the associated code - Using the "Inserted Page" Builder, we can build up pages from multiple models. These page fragments can generate calls back to the linked model or to the contained model.

Input Name	Description
Name	Enter a name for this builder call. The Designer displays this name in the Builder Call List.
Model	Use the Model Chooser to select the model that the current model will link to.
Instance Rule	Determines whether the Factory servlet generates an instance of the linked model for each request in the session or if it reuses the instance it generates for the first request. Set the value of this input to: Create new instance and state data for a session -- Sets the Factory servlet to generate a new instance for each request in the session. Always use same instance and state data for a session -- Sets the Factory servlet to use the instance of the model generated by the first request in the session for all subsequent requests. Note that This feature does not operate in the Portal environment because portlet models in that environment each have their own session. If we need to share data between portlets in the same WAR, use the Shared Variable Builder. If we need to share data between portlets in different WARs, use explicit portlet-to-portlet communication mechanisms provided by the portlet container, such as portlet wiring.
Advanced
Inherit Explicit Profile	Enable this checkbox if you want the profiled builder call inputs in the linked model to get their values from the profile passed explicitly as part of the request for the host model. The model's normal profile selection will not take place if you choose to inherit explicit profiles. All profiled inputs will get their values from the profile passed to the host model.
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.