Die Information habe ich per Mail bekommen und hoffe, dass ich noch weitere Infos vom Autor erhalte.
Habe folgenden Artikel zum Thema gefunden:
Aggregation componentSome composite applications may be composed of several pages. Simple application context can be maintained across pages using cross-page wires, which are provided by the platform and supported by the Composite Application Editor. When a page context change is desired, a property is connected to an action on another page by a cross-page wire. The act of firing the property causes the page change and instills the context into the new page. In a more complicated scenario, simply maintaining context with a single item and requiring page transitions to be coupled with context transmission may not be sufficient. Context could involve tracking multiple values, and page transitions can be initiated using other user actions.
An aggregation component is a data warehousing component. It maintains a number of values with symmetrical properties and actions for each value. When a value is set by an action, the corresponding property is fired. Additionally, when the component senses that the page it is on has become visible, it fires all known properties. The key is that the component maintains a single data model for all instances in an application. That means that, when placed on multiple pages, the values set on one page are available for retrieval on another page.
When you use an aggregation component you do not use the normal method of wiring values directly from one component to another. Instead, contextually important values are wired from the property on the first component to the action on the aggregator, and then from the corresponding property on the aggregator to the action in the destination component. In normal operation on a single page, it all proceeds the same. The property change on the first component is propagated through the aggregator to the target component. But during a page transition, the aggregator publishes all known values when the destination page is made visible. In this way, all target component(s) on the destination page are updated along with wires connected from the aggregator.
For example, a sales tracking application needs to track the current company, sales lead, and sale representative. One page may show details on a company, along with a list of the sales representatives for that company. With the sales representative selected, a pop-up window shows details about the sales representative such as phone number and email address. You can choose to create a new lead, which brings you to another page in the composite application. You want the company name and associated sales representative fields to be pre-populated based on the current value for those settings, however, and you can't do this with a simple cross-page wire.
To accomplish this, you introduce an aggregation component on the first page. Components responsible for selecting companies and sales representatives route their wires through the aggregation component. You then put another instance of the same aggregation component on the second page, where you compose a sales lead. You then wire the properties for the current company and sales representative to the corresponding input fields, and when the page switch occurs, the aggregation component detects this, fires the properties, and pre-populates the form.
(
http://www.ibm.com/developerworks/lotus/library/notes8-patterns/?S_TACT=105AGX01&S_CMP=LP)