XPath Training with Examples

Working with the Selector Engine in Afina

The Selector Engine is the central hub for Afina element targeting. It is the place where every selector, attribute query, and text match finds a home. Users get a smooth experience to pinpoint buttons, input fields, links, text blocks, and run scripts that click, hover, and extract data straight from the page. Furthermore, the engine offers reliable management of class queries, attribute filters, text content rules, and the selector data attached to each script.

Once the queries are loaded into the system, the script editor presents the entire flow on display. The best part is the convenience: a user can monitor each lookup, locate any specific selector in seconds with the matching label, and trigger lookup actions across many scripts in a single click.

Benefits of the Selector Engine

• A wide list of query patterns is available through the Selector Engine for every business need.
• Users can configure each lookup through proper class, attribute, and text matchers.
• Downstream automation scenarios easily reach into a result through the saved-variable reference.
• The engine supports both single attribute lookups and full multi-condition pipelines at any moment.
• Any user can have a smooth experience while building selector logic with a unique configuration.

Once a query is saved, the freshly-built lookup joins the rest of the entries inside the script canvas. From this point, a user can pair queries with scripts, edit each match, attach the lookup to a pipeline, mark older selectors for cleanup, link the right query to a workflow, and send the script into automation tasks. Thus, every newly-built XPath becomes immediately operational.

Searching by Class

A wide list of reasons exists to use class-based XPath in Afina. To start with, it offers brilliant speed for fresh selectors. Then a user can shift focus to the reliability with already-prepared class names. The pattern is totally effective for setting up a working environment, deploying a large batch of element lookups at once, or restoring a known good selector flow after a page change.

The most common scenario is finding an element by the value of the class attribute. The contains(@class, "...") construction handles partial matches, and the not(...) construction excludes unwanted classes from the result.

<div class="style_taskCard style_box"></div>
<div class="style_taskCard style_disable"></div>
<div class="style_taskCard style_box"></div>

//div[contains(@class, "style_taskCard")][not(contains(@class, "style_disable"))]

Furthermore, multi-class queries provide uninterrupted access to fine-grained matches. A user picks the class names and stacks them inside square brackets. The platform takes care of the rest.

//div[contains(@class, "style_taskCard")][contains(@class, "style_active")]

Searching by Attribute or Text

Different selector scenarios are available for various business needs. Users can drop a single class match at a time, or chain a stack of attribute checks inside one workflow. For exact matches, a user picks the @attribute="value" construction. For text content, the contains(text(), "...") construction handles partial matches, and text()="..." handles exact ones.

Before a query clicks through, a user should check that the targeted element is no longer wired into an active job, a script, or a workflow that is currently running. The reason is simple: a selector operation pulls related script references, tasks, page state, and work history along with the result. Thus, an unintended selector may bring extra losses.

<div data-role="admin"></div>
<button>Continue</button>
<a href="/en/auth/login">Login</a>

//div[@data-role="admin"]
//button[contains(text(), "Continue")]
//a[contains(@href, "/auth/login")]

On the other hand, exact matching is not always the right move. Many users prefer to keep an older partial match around, shift its rule, swap its attribute name, or switch the lookup to a fresh combination. The positive part is that the original query simply sits on the bench for a while without any data being permanently lost.

Recommendations and Stored Patterns

Each XPath query in Afina can carry an extensive load of selector data. The data is exactly what scripts and automation jobs reach into during execution. Some examples are class queries, attribute matches, text content rules, exact value lookups, custom attribute searches, and any other parameter that should look different from one element to the next.

The best part of this functionality is reusability. One XPath can be used everywhere with consistent results. Each script plugs in its own match whenever the call reaches the lookup step. Instead of cloning the query per script, a user simply prepares the variable correctly. Thus, automation becomes more flexible.

Furthermore, Afina offers two flavors of element targeting: partial match through contains(...) and exact match through @attribute="value" or text()="...". Partial match is reserved for content that may shift slightly across page renders. Exact match is reserved for content that stays steady across the whole site. Examples include button labels, menu items, role attributes, custom data attributes, and any other token a user wants to anchor a script on.

Both kinds of queries reach scripts through the same XPath construct. The feature is impeccable for keeping a hundred scripts wired to the same lookup in one shot. It is not limited here. Users can also pair the query with planned cleanup windows, or stash a snapshot before any major change is applied.