Understanding ViewModel Schema

This reference explains how ViewModel classes map to GraphQL schema types in the GCA, covering the patterns that distinguish view models from content models. While content models expose stored data, view models compute presentation-specific data—and unlike content types, where fields come from the Dari type system, a view type's fields come from your Java methods.

How view classes become types

A view model participates in the schema when:

1. It extends ViewModel<M> (where M is a content type for content-backed views, or your endpoint class for standalone views), and
2. It—or an interface it implements—is annotated with @ViewInterface, and
3. It is registered via entryViewClass(...) or endpointViewType(...).

The generated type is named from the @ViewInterface value if given (@ViewInterface("ArticleView") → ArticleView), otherwise derived from the class name. Customize naming globally with viewInterfaceTypeNameFunction(...).

How methods become fields

Every public getter on the view class becomes a field, named by stripping the get/is prefix and lower-casing the first letter (getSummary() → summary). The return type maps to GraphQL the same way content field types do:

Java return type	GraphQL type
String, numbers, Boolean, dates, UUID, etc.	The corresponding scalar—see Built-in Types.
Another @ViewInterface type	That view's object type—views nest naturally.
Iterable of views or scalars	A GraphQL list.
Map	A map type with entries / get(key) fields.
CharSequence containing rich text	Marked-text aware output.

Javadoc on your getters flows into the schema as field descriptions, so document your view models for your API consumers, not just your teammates.

Every view type also includes a generated _id: ID field—not the Brightspot record ID, but a stable hash derived from the model and view combination. Front-end frameworks that key components by ID (React, Vue) can rely on it for caching and reconciliation.

Request parameters

View model fields annotated with web request annotations become inputs rather than output fields. The GCA generates a <View>__RequestInput type per view, surfacing those parameters through the Response(typed: ...) argument (or the field arguments themselves for standalone views). At runtime, the GCA constructs a synthetic web request carrying your GraphQL arguments, so the same view model works identically when server-rendering a page and when serving the API.

Parameter values are always lists of strings—exactly as HTTP delivers them—and are coerced to the annotated field's Java type (Integer, Boolean, enums, etc.).

Per-field parameters

By default, request parameters are scoped to the whole view rendering. The experimental includeViewFieldSpecificTypeParameters() setting moves parameters onto individual fields, but interacts poorly with field aliasing—prefer the default unless you have a specific need.

Images and themes

Views commonly render images at named sizes. The GCA integrates with Brightspot's image-size system: when a view renders image data, the configured image sizes (from your theme or ImageSize declarations) are applied, exposing size names and their attributes (dimensions, srcset-style URLs) in the response.

Supplying a theme via themeSupplier(...) goes further: theme and style metadata become strongly-typed fields in the schema, so front ends can query style fields configured by editors. Be aware that themes are volatile—changing field definitions in the theme invalidates the schema and can break queries that referenced removed fields.

Overlays

View types support overlays—editorially configured variations of view data (e.g. style fields). Where overlays apply, view types expose an _overlay field; pass a key (or set of keys) to select which overlay data to return. Overlay values are returned as JSON.

Model access and raw views

Three settings control how much of the underlying machinery views expose:

Setting	Effect
includeModelOnViews()	Adds a _model field to view types, exposing the backing record (full type when it's a Recordable, class name otherwise).
allowRawViewAccess()	Adds a _raw field returning the entire view as a JSON map. Resolves the whole view eagerly—mind cyclic references.
excludeTypeNamesFromRawView()	Strips type/class names from _raw output when they're considered sensitive.

CDA mode: views only

For public content delivery, you may want an endpoint that exposes only view models—no record state at all. The disallowAllStateAccess() setting removes State, queries, and mutations from the schema wholesale, leaving Get lookups that resolve straight into views. Combined with onlyAllowUniqueIndexLookups() (which it implies), this reproduces the locked-down posture of the legacy Content Delivery API on modern GCA infrastructure—see the migration guide.

Next steps

• Get Content-Backed View Models and Get Standalone View Models — the operations that return these types
• Content Schema Types — the equivalent reference for content models