For Demo by Chris Whealy click here.
Supply function principles:
- A supply function is used to populate an entire node collection.
- Any context node may have a supply function defined for it.
- All singleton nodes must have a supply function defined.
- The existence of a supply function is defined declaratively.
- A supply function is called automatically by the Web Dynpro Runtime when an attempt is made to read an empty node collection
- A node collection could be empty node collection
- A node collection could be empty for any one of the following 3 reasons.
1. It has never been populated before.
2. The lead selection in the parent node collection has changed.
3. Application coding has explicitly invalidated the element collection.
Why are supply function needed?
- A supply is needed primarily to populate a singleton node's element collection.
- However if required, any context node can have a supply function defined for it.
Singleton Nodes
- It is very important to remember the difference in runtime behaviour between a singleton node and a non-singleton node. When a node is declared to be singleton, there will only ever be only one instance of that node-irrespective of the number of elements found in the parent node's element collection. This is not the case for the non-singleton node. In this case, there will be as many instances of the non-singleton child nodes as there are elements in the parent node's element collection.
- The significant point here is that when the lead selection in the parent element collection changes, the contents of the singleton child node become invalid. Consequently, the next time data is required from the singleton child node, the entire element collection must be rebuild in order that it match the data in the newly selected parent element.
- The task of rebuilding singleton child node must be performed by a dedicated supply function.
- singleton node is related to its parent node collection.
When a typical business transaction is being used, information will often be presented in the form of a list of header records of some sort; for instance, sales order headers. From this list, the user will typically select one order header and then look at its line items. It makes much better sense to read the line item information only when it is needed, rather than to read all the line items for all the sale orders in the hope that the user XYZ want to look at the information! This would be a highly inefficient application architecture both in terms of processing requirements and memory usage.When a typical business transaction is being used, information will often be presented in the form of a list of header records of some sort; for instance, sales order headers. From this list, the user will typically select one order header and then look at its line items. It makes much better sense to read the line item information only when it is needed, rather than to read all the line items for all the sale orders in the hope that the user XYZ want to look at the information! This would be a highly inefficient application architecture both in terms of processing requirements and memory usage.
No comments:
Post a Comment