Search
Contribute
Navigation
- 8.5+
- actions
- advanced features
- advantages of composite applications
- API
- app dev
- basic NSF application
- basics
- benefits
- Best practices
- Best practices
- BIRT
- browser
- built-in actions
- built-in properties
- business value
- CAE
- CAI
- catalog
- changing page properties
- compatibility
- component
- component library
- component properties
- components
- Composite Application basics
- Composite Application basics
- composite application demonstration
- composite applications
- container
- container components
- context
- creating a sidebar
- creating wiring properties
- customer interests
- data model
- debugging
- demo
- demonstration
- deploying
- deploying applications
- deploying NSF components
- deployment
- drag and drop
- easy
- ECL settings
- Eclipse
- Eclipse API
- Eclipse basics
- Eclipse components
- Eclipse samples
- Eclipse tips
- editing properties
- education
- embedded browser
- enablement
- errors
- Expeditor
- Expeditor samples
- Expeditor toolkit
- extensions
- FAQ
- feature rules
- first application
- fundamentals of Eclipse
- general debugging tips
- generic container
- getting started
- glossary
- Greenhouse
- hod
- host on demand
- how to
- Java components
- lead manager
- live text
- local
- Lotus Expeditor
- Lotus Notes component advanced development
- Lotus Notes component development in Composite Applications
- Lotus Notes components
- Lotus Notes components
- Lotusphere
- LS09
- match rules
- my first wire
- navigation
- navigators
- new applications
- new user
- new users
- Notes
- Notes 8
- Notes components
- Notes View
- Notes @formulas
- Notes8_5
- NSF-based composite applications
- NSF components
- NSFs
- opening pages
- out-of-the-box components
- overview
- page navigation
- page properties
- pages
- passing context
- PIM components
- plugins
- Portal
- product information
- product wikis
- productivity tools
- properties
- property
- property broker
- property broker editor
- Property Broker Monitor tool
- property to property
- provisioning
- questions
- resources
- roadmap
- running in context
- sample composite application
- samples
- service oriented architecture
- setting component properties
- setting up
- sidebar
- skills
- SOA
- Symphony
- Symphony view component
- toolkit
- tools
- topology peek tool
- troubleshooting
- tutorial
- Tutorials
- uninstalling composite applications
- update site
- updates
- user interface planning
- video
- view
- web container
- web services
- widgets
- wires
- wiring
- wiring properties
- wiring tutorial
- WSDL
- .ca
- @formulas
Go elsewhere
Out of the box window properties and actions
Article information
![]() |
Find out how
wiring , actions , properties |
Gregory W Roberts 10/28/2008 |
Gregory W Roberts 10/28/2008 |
The purpose of this article is to detail the built in windowing actions and properties that are available to all composite application components and show users how to enable and use them.
Lotus Expeditor provides out of the box functionality that exposes different window states of a composite application component as output properties. It also exposes actions to open, close, maximize, minimize, etc. callable actions. The properties and actions
are available to any component added to your application and can be wired in the composite application editor (CAE).
The actions are free to any component. All you have to do is enable them in the component properties of your component by adding the following preference:
com.ibm.rcp.component.enable.window.actions = true
The following output properties are available:
These output properties can be wired like any other properties in CAE
The following actions are available:
The actions of a component will be executed for the component. The component itself does not have to implement anything.
These actions are completely free to them.
Each action has an input parameter with a formatted name. The name follows the format of event.component.xxx. An example of this would be event.component.restore. Each action can call another action. This allows the application assembler to do something like
'open component A and then call this action'. To call an action you specify what action to call with the key name '.action' in the component properties. Examples of this would be event.component.open.action or event.component.close.action.
This could be a list of actions. You would use two semicolons to delimit the action names. The action must be part of the target component and enabled at the time of the event.
A brief description of each of the built in window actions
Below is a very simple example of using these built in actions and properties.
The first thing that we do is start Lotus Expeditor and create a new local composite application using the File -> Application -> New Composite Application... menu item. In our example below we named it BuiltInActionsDemo. After pressing OK on that dialog the application is open and we selection Actions -> Edit Application to open the newly created local composite application in the composite applicatine editor (CAE) for editing.
In the screen shot below you can see we have added to Managed Browser components to our application. One on the top and one on the bottom.
We edit the component properties of our second Managed Browser component - the one on bottom. You can do this by right clicking on the component and selecting Edit Component Properties... from the context menu. We select the Advanced tab of the Edit Component Properties dialog. Here you can see we set the com.ibm.rcp.component.enalbe.window.actions property to true. This will enable all of the built in actions discussed about for this particular component.

Once the actions have been enabled we close the dialog and back in CAE we select on our first Managed Browser component and select Wiring. This displays the Wiring page seen below. You can see that the Managed Browser that we are wiring too has all of the new actions as options to be wired to.
In our case we are simply going to wire our Managed Browsers Document Loaded output property to the Clone component action of the second browser. The idea here is that when the document loading is finished on our Managed Browser the property will be published to the second Managed Browser and it will clone itself.

Close the Wiring page and CAE and the application will open in Expeditor.
We enter a url of ibm.com into the top Managed Browser component. When this document is finished loading the property gets published, the second Managed Browser is notified and the clone action is invoked.
You can see in the final screen shot below that the top browser is loaded and a second instance of the bottom browser is present. It has been cloned.

![]()
The above example is a very simple one but it gives the idea of how and when to use these built in actions and demonstrates how they are free to use by any composite application component created by anyone.
Lotus Expeditor provides out of the box functionality that exposes different window states of a composite application component as output properties. It also exposes actions to open, close, maximize, minimize, etc. callable actions. The properties and actions
are available to any component added to your application and can be wired in the composite application editor (CAE).
The actions are free to any component. All you have to do is enable them in the component properties of your component by adding the following preference:
com.ibm.rcp.component.enable.window.actions = true
The following output properties are available:
- Component Closed
- Component Opened
- Component Activated
- Component Deactivated
These output properties can be wired like any other properties in CAE
The following actions are available:
- Clone Component
- Close Component
- Maximize Component
- Minimize Component
- Open Component with data
The actions of a component will be executed for the component. The component itself does not have to implement anything.
These actions are completely free to them.
Each action has an input parameter with a formatted name. The name follows the format of event.component.xxx. An example of this would be event.component.restore. Each action can call another action. This allows the application assembler to do something like
'open component A and then call this action'. To call an action you specify what action to call with the key name '
This could be a list of actions. You would use two semicolons to delimit the action names. The action must be part of the target component and enabled at the time of the event.
A brief description of each of the built in window actions
- Close Component: this action simply closes the view part. It does nothing else. Any data passed into the action is ignored
- Maximize Component: this action does a show view with the maximize flag passed in
- Minimize Component: this action does a show view with the minimize flag passed in
- Restore component: this action does a show view with the restore flag passed in
- Open component with data: this action is registered whether the component is visible or not. This action also takes the input of the action and can optionally assign the value as a string to the target component data area. So, the component can have new data posted to its application preferences when it is opened.
- Clone component: the clone action is similar to the open action except that it actually clones the component and will allow N number of them to be on the screen at once. Please note that the cloned component is not part of the application. So, if the client is shut down and re-opened the clones will not initialize.
Below is a very simple example of using these built in actions and properties.
The first thing that we do is start Lotus Expeditor and create a new local composite application using the File -> Application -> New Composite Application... menu item. In our example below we named it BuiltInActionsDemo. After pressing OK on that dialog the application is open and we selection Actions -> Edit Application to open the newly created local composite application in the composite applicatine editor (CAE) for editing.
In the screen shot below you can see we have added to Managed Browser components to our application. One on the top and one on the bottom.
We edit the component properties of our second Managed Browser component - the one on bottom. You can do this by right clicking on the component and selecting Edit Component Properties... from the context menu. We select the Advanced tab of the Edit Component Properties dialog. Here you can see we set the com.ibm.rcp.component.enalbe.window.actions property to true. This will enable all of the built in actions discussed about for this particular component.

Once the actions have been enabled we close the dialog and back in CAE we select on our first Managed Browser component and select Wiring. This displays the Wiring page seen below. You can see that the Managed Browser that we are wiring too has all of the new actions as options to be wired to.
In our case we are simply going to wire our Managed Browsers Document Loaded output property to the Clone component action of the second browser. The idea here is that when the document loading is finished on our Managed Browser the property will be published to the second Managed Browser and it will clone itself.

Close the Wiring page and CAE and the application will open in Expeditor.
We enter a url of ibm.com into the top Managed Browser component. When this document is finished loading the property gets published, the second Managed Browser is notified and the clone action is invoked.
You can see in the final screen shot below that the top browser is loaded and a second instance of the bottom browser is present. It has been cloned.

The above example is a very simple one but it gives the idea of how and when to use these built in actions and demonstrates how they are free to use by any composite application component created by anyone.
Comments
1) Not a really good example
Why should I want an empty browser window to be cloned when another browser is finished loading?
What's the use case?
2) Idea for a use case
What comes to my mind here is a "web browser ca", e.g. a text field to enter a list of URLs and a "go" button next to it.
When I hit the "go" button, this creates one browser component for each URL. The browser components should be displayed as tabs in one row, not as separate windows.
All the browser components are wired to an info panel that displays some information for the currently active browser component (e.g. data from parts of the web page and outgoing links) and changes its content when I click on a different browser tab.


