Variable Builder Input - Portlet Factory v6.1.2

Portlet Factory, Version 6.1.2

Variable Builder Input

+
Search Tips | Advanced Search

The Variable builder takes the inputs described in this table.

Input Name Description
Name Name for this builder call. The WebSphere Portlet Factory Designer displays this name in the builder call list.
Type Enter the data type for the value that the variable will hold from one of the following choices:

String
Integer
Double
Float
Long
Boolean
XMLData
Object

In addition to these standard data types, you can also declare variables to be of a type defined in a schema that you have added to the model with the Schema builder.
Note: Schemas that define many elements could cause an Out of memory error due to the fact that those elements need to be displayed as possible types by the Reference Chooser.
(Optional) Namespace Enter the URL to the schema definition. If the schema referenced in the Schema builder call includes an xmlns declaration, that value is used to prepopulate this input.
(Optional) Namespace prefix Enter a string that will be prepended to element names in the XML structure. For example, you could differentiate between two Address types by using a namespace prefix, perhaps ba for a billing address and sa for a shipping address.
<sa:Sample xmlns:sa="http://bowstreet.com/2002/03/datamapper"> <sa:firstName>Sample firstName</sa:firstName> <sa:lastName>Sample lastName</sa:lastName> <sa:address1>Sample address1</sa:address1> <sa:address2>Sample address2</sa:address2> <sa:city>Sample city</sa:city> <sa:state>Sample state</sa:state> <sa:zip>Sample zip</sa:zip> <sa:phone>Sample phone</sa:phone> <sa:email>Sample email</sa:email> </sa:Sample>

Initial Value Enter the value of this variable.
Note: You can use an indirect reference or a method to populate this variable with a value from another model entity, such as the return from a service call.
When you specify an indirect reference such as ${Variables/foo}, the builder will use the indirect reference when the variable is first accessed and prior to any initialization.
Advanced

Instantiation Method Select or enter the name of the method you want to use to instantiate this variable. The choices you have in the select list will depend on the methods you have made public within the model.
State and Failover You can determine the failover behavior for variables by choosing a setting for the Persist Choice property in the Variable builder call editor. 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.

Note: Do not use Request Scope for items that are used in multiple requests, such as XML variables. 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.
Initialize every fetch Enable this input if you want the Initialize Via action to get called each time the variable is accessed. If the variable does not use an Initialize Via action, enabling this input has no effect on the variable's initial value.
Regen sample data Enable this input if you want the initial value to be generated from the associated schema type.
Leave this input disabled if you want to retain the initial value of the variable during subsequent generations of the 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 LJOs that builder adds to the WebApp. The Domino View and Form builder does not provide an LJO Class Name input. But, you 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, and so on), rename it, and then create a replacement object.

Note: 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.

Parent topic: Variable builder

Library | Support |

Input Name	Description
Name	Name for this builder call. The WebSphere Portlet Factory Designer displays this name in the builder call list.
Type	Enter the data type for the value that the variable will hold from one of the following choices: String Integer Double Float Long Boolean XMLData Object In addition to these standard data types, you can also declare variables to be of a type defined in a schema that you have added to the model with the Schema builder. Note: Schemas that define many elements could cause an Out of memory error due to the fact that those elements need to be displayed as possible types by the Reference Chooser.
(Optional) Namespace	Enter the URL to the schema definition. If the schema referenced in the Schema builder call includes an xmlns declaration, that value is used to prepopulate this input.
(Optional) Namespace prefix	Enter a string that will be prepended to element names in the XML structure. For example, you could differentiate between two Address types by using a namespace prefix, perhaps ba for a billing address and sa for a shipping address. <sa:Sample xmlns:sa="http://bowstreet.com/2002/03/datamapper"> <sa:firstName>Sample firstName</sa:firstName> <sa:lastName>Sample lastName</sa:lastName> <sa:address1>Sample address1</sa:address1> <sa:address2>Sample address2</sa:address2> <sa:city>Sample city</sa:city> <sa:state>Sample state</sa:state> <sa:zip>Sample zip</sa:zip> <sa:phone>Sample phone</sa:phone> <sa:email>Sample email</sa:email> </sa:Sample>
Initial Value	Enter the value of this variable. Note: You can use an indirect reference or a method to populate this variable with a value from another model entity, such as the return from a service call. When you specify an indirect reference such as ${Variables/foo}, the builder will use the indirect reference when the variable is first accessed and prior to any initialization.
Advanced
Instantiation Method	Select or enter the name of the method you want to use to instantiate this variable. The choices you have in the select list will depend on the methods you have made public within the model.
State and Failover	You can determine the failover behavior for variables by choosing a setting for the Persist Choice property in the Variable builder call editor. 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. Note: Do not use Request Scope for items that are used in multiple requests, such as XML variables. 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.
Initialize every fetch	Enable this input if you want the Initialize Via action to get called each time the variable is accessed. If the variable does not use an Initialize Via action, enabling this input has no effect on the variable's initial value.
Regen sample data	Enable this input if you want the initial value to be generated from the associated schema type. Leave this input disabled if you want to retain the initial value of the variable during subsequent generations of the 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 LJOs that builder adds to the WebApp. The Domino View and Form builder does not provide an LJO Class Name input. But, you 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, and so on), rename it, and then create a replacement object. Note: 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.