Views, Elements, and Identification

Your automation logic is full of statements like "click on Sign In button" or "enter text in Username". For those statements to run reliably, ACCELQ must be able to find each of those elements again at execution time, on a build of the application that may have changed since you recorded. This article explains the machinery that makes that work: Views, the Element Repository, and identification strategies, and how they connect. In day-to-day recording you rarely think about any of this, because it happens automatically; understanding it pays off when you maintain logic over time.

Elements

An Element is a UI field or control that your logic interacts with or verifies: a button, an input field, a dropdown, a label. Every recorded statement that touches the screen refers to an element, and how that element is identified determines how resilient your logic is to application changes.

Views

A View is a snapshot of a screen and its underlying structure: a web page and its DOM, or a mobile screen and its element tree. Views serve two purposes:

• Identification. For repository-based elements, ACCELQ references the attributes captured in the View to locate the element at runtime.
• Offline access. You can open a View from the VIEWS panel and record additional statements from it, right-clicking its elements just as you would in the live application. This lets you incrementally update logic even when the application is not available.

Views are captured automatically. As you record, ACCELQ captures the Views it needs behind the scenes and avoids redundancy: multiple elements recorded from the same screen share a single View. You do not manage Views during recording.

Views belong to the Context. All Actions in a Context share the same Views (and elements). When you record from within an Action, captures are associated with that Action's owner Context.

The Element Repository

The Element Repository is the centralized store of saved elements for a Context. Each entry carries:

• A logical name, which is how your statements refer to it ("Sign In Button")
• The element type (input, button, label, and so on), which determines the commands applicable to it
• Its identification attributes, per the strategy it was saved with
• Optional Element Instances (see below)

Elements are saved to the repository automatically as you record, with generated names you can rename later, and recording on the same element again reuses the existing entry. Manage the repository from the ELEM panel in the recorder sidebar: review elements, edit identification, rename, or delete unused entries.

Repository entries are scoped to the Context. All Actions in the same Context share them; elements from one Context are not directly accessible in another.

Identification Strategies

ACCELQ supports several strategies for identifying elements, and they fall into two families:

Repository-based strategies store the element in the Element Repository and identify it through captured attributes:

• Smart Locator. Builds a composite identifier from a stable combination of the element's attributes. Designed for resilience: if one attribute changes in a new application build, the others can still identify the element. Available in every recorder type.
• XPath (Mobile Recorder). Identifies the element by its position and attributes in the UI hierarchy. Precise and fast, but tied to the structure, so more sensitive to layout changes.

Statement-embedded strategy skips the repository entirely:

• Locator-Free (Web, PDF, and Electron Recorders). An AI-powered algorithm detects the functionally significant label for the element, and that hint is embedded directly in the statement: "enter 'admin' in Username". There is no element to save, no View required, and nothing to maintain. Because identification is based on what the screen means rather than how it is coded, the logic is resilient to changes in the underlying markup.

Availability by recorder type:

The Mobile row covers native elements. Web content inside a WebView, captured in Web Mode, follows the web strategies instead; see WebViews in Hybrid Apps.

Which strategy applies when you record, and how to choose or override it, is specific to each recorder type: see Locator-Free and Smart Locator for web (also applicable to PDF and Electron) and Smart Locators and XPath for mobile.

Element Instances: One Element, Multiple Definitions

Sometimes the same logical element needs different identification in different situations. A Sign In button may have entirely different technical properties on iOS and Android, or a different structure at phone resolution than at desktop. Element Instances solve this: a single repository element carries multiple identification definitions, and ACCELQ picks the right one at runtime. Your logic always refers to one name, "Sign In Button", regardless.

Two applications of the concept:

• Platform instances (Mobile): separate iOS and Android definitions, enabling write-once, run-on-both logic. See Cross-Platform Portability: iOS and Android.
• Breakpoint instances (Web): separate definitions for desktop, tablet, and phone breakpoints in responsive applications. See Device Emulation and Breakpoints.

How It All Connects

Repository-based recording (Smart Locator, XPath):

1. You record a step on an element.
2. ACCELQ captures a View of the current screen (if not already captured).
3. The element is saved to the repository with attributes drawn from the View.
4. The statement references the element by its logical name.
5. At runtime, ACCELQ uses the stored attributes to find the element.

Locator-Free recording:

1. You record a step on an element.
2. The AI detects the element's label hint.
3. The hint is embedded directly in the statement. No View, no repository entry.
4. At runtime, ACCELQ finds the element by its label hint.

The practical difference: repository-based elements give you central management, reconciliation after UI changes, and Element Instances; Locator-Free gives you zero management overhead and resilience to markup changes. Most projects use both, guided by the project preference and per-element overrides described in the recorder-type articles.