Skip to end of metadata
Go to start of metadata

This spec is out of date! New spec page in google docs


KRAD should support the display of and user interaction with application forms that have arithmetic calculations/relationships among form fields that must be met.  For example, the user should be able to see the results of entries they make into form fields that affect the total (or other value) elsewhere on the form.  In this way, users are given helpful feedback about numeric values they enter, "live" and inline in the form, while they are filling it out, without having to submit it to see the results of calculations.

In addition, KRAD should support the optional display of table-based data, inline in the table itself, of additional properties associated with each row.  See the Mocks and Diagrams section below.

Detailed Description

See the Requirements section below.

Usage Scenarios

See the Mocks and Diagrams section that follows.

Mocks and Diagrams

1. Existing Examples of Totals defined by Groups

1.a. Totaling of columns displayed below collection (could be in last row) and/or displayed in any other field on the page

Below is an example showing automatic updating of the total amount, based on entries in a collection.  In this example, the total shown at the bottom of the collection is read-only, based on the amounts in the collection rows.  In KNS, updating the totals typically requires a refresh of the page.  A requirement in KRAD, is to be able to make this into a conditional refresh of the totals field or, alternatively of the collection, with the objective being to not require a refresh of the entire page:

A variation on this example above could be a matching of a target total with the amounts entered per row, displaying a client-side validation error if/when the amounts entered exceed the total amount allowed.

1.b. Grouping and Totaling - Totals defined by groups

Below is an example from KFS, in which the user can "Drill Down" to view the balances by Object Code:

Note: KFS adds up the balances displayed above it by various attributes that are not shown in the UI, for example, by income or expense; budget, actual or encumbrance; transfer activity, and so on.  Therefore, you might not be able to intuit the calculations from the #s shown in the user interface in this example above.

2.  Existing Examples of Master/Detail relationships

2.a.  Details as additional properties of the row

In the following example, the details are additional properties of the row, that are displayed (laid out) out in a way that is conceptually similar to a sub-grouping (though these details are not actually a subgroup/subcollection, they are additional properties of the row displayed in this way).    These could be displayed conditionally (in a way similar to drilling down - see example 2.b., or by default as shown in the example below:

2. b.  Details conditionally displayed by the user, rather than displayed by default at all times

Details such as those shown above can be conditionally shown, enabling a collapsed and more expanded view by row similar to show/hide).  In this example below, the rows are grouped by attributes and allow drill down (& show/hide all could be supported for the entire collection) for the detail records.

Alternative ways to show or hide details, under user's control, are shown below:

And ...


If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):


Requirements Listing

  1. KRAD should support arithmetic functions enabling an application to perform arithmetic operations on an identified set of table/collection cells, and to place the results of the calculation(s) anywhere on the page.  For example:
    1. The result of the calculation could be placed in a final row at the bottom of a collection (in the same column where most of the values included in the arithmetic function are).
  2. KRAD should support placing the result of a calculation into a read-only field and into an editable field (these two options should be available for applications to select from).
  3. KRAD should enable applications to update the field(s) that contain(s) the result of the calculation "real-time":
    1. This could be a conditional refresh relationship between fields or a refresh of the entire subcollection / collection.
    2. The UX recommendation to applications is to refresh just what is needed (in some cases that may be an entire collection/section).
  1. More complex arithmetic calculations would be nice to have (more advanced statistical functions, such as standard deviations, t-tests, analysis of variance, linear regression, and so on).
    1. The required arithmetic operations that must be supported are
      1. simple addition
      2. subtraction
      3. multiplication
      4. division
      5. combinations of the above
  2. It would also be nice to have the capability to associate a non-modal pop-over (like a large tooltip) with a table/row in order to display additional details that are related to that row/item, but that are not programmatically encoded as additional details on the row. 
    1. For example, to make a call out to the server to bring in another form/view related to that item, and display it in a non-modal pop-over.
    2. To be able to traverse the table, with the pop-over remaining open, while the content is refreshed depending on which row is selected (e.g., a KC requirement). 
  3. KRAD should support a way for the user to optionally display (and then to remove from the display) additional properties of the row, inline in the view. 
    1. More detail on the UI specifics to be added here after review of the datatable plug-in's options.  For example, whether this will be a simple expand/collapse control, and so on.
  4. The application should be able to add constraints and dependencies between the totals field and the fields involved in the calculation.  For example,
    1. It should be possible to define a total figure (in a read-only field) and enforce that the values of the fields involved in the calculation cannot add up to more than this figure (or must add up to exactly this figure).
    2. Client-side validation should be able to support these types of dependency constraints.

(Item 2 is listed in the secondary requirements section as it is unknown if this item would require a larger work effort than can fit within the 2.2 development cycle timeframe.  For more on this, see KRAFDBCK-8143)


List any functional or technical work that must be completed before work on this item can begin:

  1. Determine whether the jQuery datatable plug-in can support the master-detail relationship expand/collapse or whether custom KRAD functions will need to be developed.


List any issues that need to be resolved before work on this item can begin:

  1. Currently only showing read-only in the examples, but we need to have the ability to do this in editable items with validation. Need examples of that.
  2. item
  1. item
  2. item

QA or Regression Testing Plan

List steps needed to test the basic functionality of this update, enhancement, bug fix

  1. test/steps
  2. test/steps


Functional Analysis Complete? No (completed by SME)

Needs Review by KAI? No (completed by SME)

Technical Analysis Complete? No (completed by DM)

Needs Review by KTI? No (completed by DM)

Estimate: 30 hours (completed by DM)

Technical Design: Link Here (completed by DM)

Jira: KULRICE-7682 

Final Documentation: Link Here (completed by DM)

Added to QA: No (completed by SME)

  • No labels