Pair framework: View class

Pair\Core\View is the legacy HTML view layer in Pair v4.

It remains available only as a migration bridge for classic Pair MVC modules. New Pair v4 modules should not introduce new View subclasses. They should return PageResponse from Pair\Web\Controller and pass a typed page-state object directly to the layout. The legacy view base emits a deprecation notice outside production.

Legacy responsibilities

A classic Pair view is responsible for:

• preparing data via a Model
• assigning variables to the layout through assign()
• rendering a layout file in layouts/*.php
• exposing helpers such as translation, pagination, and sorting

In Pair v4, those responsibilities are split more explicitly:

• the controller orchestrates
• the controller loads or maps data
• the page state carries the layout contract
• the layout renders that typed state directly

Legacy naming convention and layout resolution

Pair determines the module name and the default layout from the View class name.

Example:

• UsersViewDefault -> module name users
• UsersViewDefault -> layout default
• layout file -> modules/users/layouts/default.php

This auto-resolution still works for legacy modules, but it is no longer the preferred v4 path.

Legacy lifecycle

Construction

A legacy view is created by passing a Model instance:

$view = new UsersViewDefault($model);

At construction time Pair automatically:

• loads Application, Router, and Translator
• emits a non-production deprecation notice for the legacy view class
• builds modulePath, moduleUrl, and the default layout
• creates Pagination
• attaches pagination to both the view and the model
• calls the optional _init() hook

_init(): void

Override _init() in child views only in classic legacy modules. If _init() is setting page title, breadcrumbs, menu state, or loading records from $this->model, that logic should move into the controller during Pair v4 migration.

render(): void

Every legacy view must implement render().

This is where old Pair modules usually:

• read router state
• call the model to fetch data
• assign variables to the layout using assign()

In Pair v4 this data-loading and mapping work should move to the controller, which then returns a typed page state.

display(?string $name = null): void

display() executes render() and includes the layout file. This is the classic HTML rendering path and should be treated as a compatibility layer in Pair v4. When Observability is enabled, Pair records view.render and view.layout spans around this legacy path.

Legacy layout variables

assign($name, $val): void

Adds a variable to the internal layout bag. Layouts then access it through $this->name.

This is one of the main migration targets in Pair v4. The upgrader can generate readonly *PageState skeletons from assign() usage so the layout contract becomes explicit.

assignState(object $state): void

Stores a typed state object on the legacy view. This can be useful as a migration step, but the preferred end-state is to stop using Pair\Core\View entirely and return a PageResponse from Pair\Web\Controller.

Recommended Pair v4 migration shape

1. move record loading out of the view and into the controller
2. replace assign() variables with a typed page-state object
3. update layouts to read $state->... directly
4. stop instantiating the legacy view and return PageResponse explicitly

See also: Controller, Observability, Upgrade-to-v4, Pair-v4-Design