Implement attributes to return top-level screen data

You must add new Display attributes to your case rule class to identify data that must be made available for display.

For calculated data which is already implemented via eligibility/entitlement calculations, you should implement an attribute to obtain this data. Typically you will use CER's <create> expression to create an instance of the eligibility/entitlement rule object (specifying the productDeliveryCase value passed in), and then use CER's <reference> expression to obtain data from the eligibility/entitlement rule object. The eligibility/entitlement rule object will tend to be required by many Display attributes and can be created in its own rule attribute which is not annotated with Display.

For data which requires display-specific calculations, then you must implement these calculations. Typically any intermediate steps in these calculations are not required for display, and so any attributes you implement for intermediate-only steps should not be annotated with Display. You may also create your own display-specific rule classes which contain a mixture of Display/non-Display rule attributes.

For a list of data items, you will typically use CER's <dynamiclist> expression to transform a list of data into a list of "wrapper" rule objects, where each rule object has annotated attributes which identify which values to display and which provide any display-specific calculations.

For example, you may require a summary display category to show the following:

• The name of the claimant;
• The number of people in the household; and
• A list of assets owned by the claimant.

You identify that all these details are available by manipulation of data already used in eligibility/entitlement calculations, and so your decision details need to create an instance of your eligibility/entitlement rule class (as is typically the case).

The name of the claimant can be obtained by navigating to the person rule object already retrieved by your eligibility/entitlement rules, and so create a claimantName Display attribute on your case rule object, which navigates the eligibility/entitlement rules to obtain the required data.

The number of people in the household is not directly relevant to eligibility/entitlement rules, so you implement a householdCount Display attribute which retrieves the list of household members from your eligibility/entitlement rules and then provides display-specific processing to count the number of items in the list.

To display the list of assets, you implement a rule class named AssetDisplay with the responsibility for display each asset. You implement an assets rule attribute on your case rule class which retrieves the eligibility/entitlement Asset instances and for each one creates an AssetDisplay instance, passing in the eligibility/entitlement Asset instance.

In pseudo-code, your case rule class ends up containing rule attributes like this:

• eligibilityEntitlementCase (not annotated with Display):
  • Create an instance of the eligibility/entitlement rule class for the product, specifying the value of productDeliveryCase
• claimantName (annotated with Display):
  • Retrieve the value of personName from the value of claimant from the value of eligibilityEntitlementCase worked out above (or, in a more Java-like notation, eligibilityEntitlementCase.claimant.personName)
• householdCount (annotated with Display):
  • Retrieve the value of householdMembers from the value of eligibilityEntitlementCase worked out above; and
  • Count the number of items in the householdMembers list.
• assets (annotated with Display):
  • Retrieve the value of assets from the value of eligibilityEntitlementCase worked out above.
  • For each asset, create an instance of AssetDisplay, passing in the current asset.
  • Return a list of AssetDisplay instances.