Selectors / Selector Lists

Essbase Selector objects define that the user will select a value from a given dimension and a Dodeca Token will be assigned the value. The Selector object itself, however, is not aware of the content nor is it aware of the user interface. Instead, the associated Selector List object is responsible for defining the content and the user interface.

At runtime, the Selector is created, configured, and filled with members based on the connection defined for the selector list. The default connection used is the connection defined for the view.

The internal mechanisms of the Selector and Selector List object understand the differences between connections and will optionally cache, for the Dodeca session, based on relevant connection information. For example, take two Essbase connections to databases that each have a Product dimension. Dodeca will track each use of the Selector List based on its connection and, if the Product dimensions differ between the two databases, will properly resolve the Selector List based on the contents of each database. As such, it is best practice in this case to have only one Product selector and thus only one Product token.

There are situations, however, when you may need the end user to select two distinct members from the same dimension. For example, a view may require a user to select a 'Base Scenario' and a 'Comparison Scenario'. In these special cases, it is appropriate and recommended to create a second Selector (and a second token) for such a dimension.

Essbase treeview selector lists have built-in functionality to query for related outline members. By default, selector lists build from the top down based on one or more root nodes defined by the Dodeca developer. The treeview is initially filled with the root nodes and their children. As each generation is expanded, the children are queried from the server if they have not been previously cached.

Treeview selectors may be configured to build the nodes from a lower level up towards the top. In that case, the BaseMemberNodePolicy is set to AddBaseMemberAsDescendantNode causing the selector list to add the list of members as leaf nodes in the tree and build the hierarchy upwards to the given termination point or to the dimension level if no specific BaseMemberAsDescendantNode_RootNodeMemberValue is specified.

Building the tree hierarchy from the top down incrementally, which is the default configuration, runs faster as it builds only the portion of the treeview requested by the user and nothing more. When a treeview is optionally built from the bottom up, the entire treeview must be queried and filled into the treeview before it is presented to the end user.

If a dimension or a portion of a dimension to be displayed in the selector is small, say less that 250 members, it is faster to call the server once for all the members to be displayed. The Prefill property of the selector list is used to flag the selector list to fill the entire selector with a single call to the server.

Selector lists can be configured to cache queries to the server for the duration of the Dodeca session and, for most selector list types, caching is turned on by default. For report script selector sources, however, session caching is off by default as we believe that many report script-sourced lists may be based on members subject to missing data suppression.

There is one use case where selector list caching may not be desirable. When a dimension is changing frequently during the work day, it may be preferable in this case to turn off session caching for that given selector list.

The MaxLevelSelectable property is used to force users to select a member at a lower level of an Essbase outline. For example, it is necessary for an end user to choose a bottom level member for a budget, for example, setting the MaxLevelSelectable property to 0 forces the user to select a member at the bottom level. When the MaxLevelSelectable is set to 0, the user can click on upper level members to navigate the hierarchy, but the Build View button, which initiates building the view, is disabled unless the user has selected a bottom level member.

By default, the listbox control used for EssbaseSelectorTreeview and EssbaseSelectorListbox selector control types will automatically size based on the contents. This can sometimes be distracting. In order to set the control width to a fixed value, set both the SelectionTextMinCharacters and SelectionTextMaxCharacters to the same value to make the text box a fixed width.

The NullSelectionText property value is used for multiple reasons. First, it prompts the end user for an appropriate value. In addition, the NullSelectionText value is used to initially size a control in the case where the controls are set to autosize. This is especially important as the default width for controls is zero which effectively makes them invisible.

The TokenForMemberNameAndAlias property, when set to true, returns a token for both the member name and the alias. For example, suppose a selector for the Market dimension has a token [T.Market]. The value assigned to the token is based on the value of the UseAliases property. When UseAliases is set to false, the token will contain the member name and if the UseAliases property is set to true, the token will contain the alias. There are occasions, however, when it is preferable to have the value of the member available even when the view displays aliases. One example of this is when using tokenized values for comment key/value pairs; we recommend these always be based on the member name.

If the TokenForMemberNameAndAlias property is set to true, additional tokens will be generated for the alias and the member name. In the above example, in addition to the [T.Market] token, the additional tokens [T.Market.Name] and [T.Market.Alias] will be generated containing the member name and alias respectively.