Implicit value restrictions are often overlooked during the
preliminary analysis
of an infotype. The primary examples of implicit value restrictions are radio buttons and checkboxes. If a radio button or checkbox is present on a screen, then only two input values are possible –
‘_’
(that is, inactive) and
‘x’
(that is, active); this restriction is enforced by the user interface itself. Nonetheless, radio buttons and checkboxes serve as checks, and as such, they must be considered accordingly in the business logic.
Note
Always remember that in direct input situations, no dynpro processor is present to prevent the user from specifying other values in these fields. Therefore, you must make certain to encode these checks in the business logic, even if this action may initially seem to be redundant.
Another example of implicit value restrictions is found in dynpros that
LOOP AT SCREEN
in order to disable input for certain fields. This command presupposes that the fields in question are bound to a predefined value – typically space or initial – that is filled at Process Before Output (PBO). However, as with radio buttons and checkboxes, you cannot prevent these fields from being filled in a direct input situation. Thus, as with checkboxes and radio buttons, you must encode checks for the contents of these fields, even when such checks may seem to be redundant, as when the fields are assigned to a dynpro and therefore have anticipated values.