Construct Application Development

Control Status Manipulation Overhead Minimization

Complex logic to determine whether to enable, disable, or hide page elements can often have the biggest negative impact on page performance. Since there are several different sets of control status manipulators, it can be difficult to pick the right one based on the context of the page.

Refer to Control Views for more information.

This section contains these topics:

Control Status Fields

This feature has been deprecated due to the complexity it can add to views which are laden in control status fields, but in very simple cases, it can be utilized without bloating the data views. Control Status field is a field within the pages view (Horizontal, Vertical, Toolbar, etc.) which acts the same way as a Data Control View.

When used sparingly, it can result in pages that perform well and are still easy to understand.

Precedence

The simplest optimization that can be made to most pages is control view record reduction. UCVs and DCVs are usually the biggest offenders of unnecessarily large record sets.

The majority of the time a DCV is created, it selects the entire record set and does something like:

SELECT CASE WHEN [Field] = 1

THEN 0 --Disabled

ELSE 1 -- Enabled

END as [Enabled]

FROM [Table] WHERE [Field]

However, DCV’s do not require every record to be present. If it’s expected that more than often records will be DISABLED as opposed to ENABLED the DCV should change to:

SELECT 1 as [Disabled] FROM [Table] WHERE [Field] <> 1

where the Control Status is set to Enabled by default within the pages configuration.

This does several things:

  • Reduces the record set site, improving performance

  • Reduces the complexity of the view, improving performance

  • Simplifies the view, making it easier to understand

Consolidation

Another problem is making sure you choose the most appropriate control mechanism to achieve the end goal. Most individual mechanisms can implement the same behavior in one way or the other. However, some may require much less computational logic.

An example of this is that a DCV can contain a boaUser Email, which can allow for a cell to be controlled exclusively off of the boaUserEmail. For instance:

SELECT boaUserSel.[UserEmail] as boaUserEmail,

[Table].[KeyField],

CASE WHEN boaUserSel.[UserEmail] like ‘a%’ THEN 1 ELSE 0 END as [ControlledField]

FROM [Table] CROSS JOIN boaUserSel

Instead of a DCV, this should be a UCV, which would reduce the logic to

SELECT boaUserSel.[UserEmail] as boaUserEmail,

‘ControlledField’ as boaColumn,

CASE WHEN boaUserSel.[UserEmail] like ‘a%’ THEN 1 ELSE 0 END as [boaControlStatus]

FROM boaUserSel

This would result in the pages performance scaling linearly against the applications User count, as opposed to a multiplication of Users * Table Data.

Simplification

The biggest performance gains most often come from SQL simplifications. Becoming a SQL expert will be the best way to ensure complex pages will perform at their best.

For example, the following view:

SELECT boaUserSel.[User Email] as boaUserEmail, ‘ControlledField’ as boaColumn, CASE WHEN boaUserSel.[UserEmail] like ‘a%’ THEN 1 ELSE 0 END as [boaControlStatus] FROM boaUserSel

Could be:

 

SELECT boaUserSel.[UserEmail] as boaUserEmail, ‘ControlledField’ as boaColumn, 1 as [boaControlStatus] FROM boaUserSel where boaUserSel.[UserEmail] like ‘a%’