Data changes

For data changes, it is best to limit the fields that can be modified by the client, and validate the changed values when applicable. Again the name change example applies here. You can allow the client to change their first name and then just validate the correct characters are contained in the updated name on the server side.

A new scripting API has been created to indicate if a component is modifiable by the client.

• IPFPropertyI -> ClientModifiable: Initialized to the value of the Enabled check box from the Layout Editor. This is available only in server-side scripting.
• IPFUnboundComponentI -> ClientModifiable: Initialized to the value of the Enabled check box from the Layout Editor. This is available only in server-side scripting.

The initial value of IsClientModifiable is set to the valued specified by the Enabled check box in the Layout Editor. When server-side scripting changes Enabled, the IsClientModifiable flag is also changed to the same value by the IPF architecture. To allow client modifications when Enabled is not true, server-side scripting can explicitly set the IsClientModifiable flag to true. When IsClientModifiable is true, the architecture assumes that data changes from the client are expected and allowed on this field. For these fields, the existing scripting implementation should already be doing validation on the data, since changes are coming from the client. When client scripting sets Enabled to true, if IsClientModifiable is not true, any data change made in the enabled component is dropped at the server. If the client scripting makes a data change to a component or property and IsClientModifiable is not true, any data change made is dropped at the server.

The IPFDropdown field display formatter has additional values that can be specified. These additional values go into the target properties causing a data change. These changes happen on the server side, so IsClientModifiable does not have to be set to true for these components.