Concepts

Core Concepts

Core Concepts

The Fluent Interface

GPAL's fluent interface is its defining characteristic. Every subsystem, every operation, every configuration option is expressed through the same chained method syntax - readable by anyone, consistent across 19 of the 21 possible engine and browser combinations.

One Pattern, Every Subsystem

Whether you are controlling a browser, automating a desktop application, reading from Excel, converting data formats, sending email, or querying a database. GPAL uses the same fluent chaining pattern throughout. There is no context switching, no separate API to learn for each subsystem. You learn the pattern once and apply it everywhere.

Reads Like a Workflow

A GPAL workflow reads like plain English instructions. Non-developers can follow what a workflow does without understanding C#. This is not an accident. It is the core design goal. The fluent interface enforces correct usage (defaults are used if none supplied) so the workflow runs as intended. The method names describe the intent, not the implementation.

// Browser automation - reads like instructions

browser.GoTo("https://example.com")

.WithSelector("#username")

.WithSelector("#password")

.FillInFrom(credentials)

.WithSelector("#login")

.LeftClick()

.WithSelector(".welcome")

.GetGrid(out IGPALGrid<string> greeting);

// Data operations - same pattern, different subsystem

IGPALGrid<string> grid = GPAL.Grid.ToGPALObject();

grid.InputFrom("data.csv");

grid.SaveTo("data.json");

TIP

GPAL supports 3 browsers and 7 engine variants. 21 combinations on paper, 19 that are actually usable (Puppeteer does not work with Firefox). Your workflow code is identical across all of them. Switching engines or browsers is a single configuration change, not a rewrite.

Why This Matters

Traditional automation code mixes infrastructure concerns with workflow logic, making it brittle, hard to read, and difficult to maintain. GPAL keeps configuration and action separate so workflows are always clean. Workflows become self-documenting artifacts that the whole team -- developers, QA, analysts, managers -- can read and validate. This is why GPAL exists.

// A plain string works -- no Selector variable needed

browser.GoTo("https://example.com")

.LeftClick("#username")

.FillInFrom(credentials);

// Name a selector for cleaner logs and error messages

Selector loginBtn = GPAL.Selector

.WithCSS("#login")

.WithXPath("//button[@type='submit']")

.WithSelectorName("Login Button")

.ToGPALObject();

browser.LeftClick(loginBtn);

TIP

A plain string is implicitly converted into a Selector for you. Reach for the full GPAL.Selector form when you need CSS and XPath fallbacks or a named selector.

WARNING

IntelliSense will not always narrow to exactly the right next step. This is a natural consequence of how C# interfaces compose. Check the Endpoints docs when a chain does not look right.

On this page

Core Concepts
The Fluent Interface
  • One Pattern, Every Subsystem
  • Reads Like a Workflow
  • Why This Matters