Skip to the content
Documentation
Help Start
Reading in:
  • German: 9,059 of 9,059 pages
About the help in other languages
All help pages

Content classes for apps

Map Exponential content classes to app screens - finding the classes and fields a folder holds, reading class definitions with expclass services, classIdentifier as the switch for cells and views, handling unknown…

Download as PDF

Address: https://doc.exponential.earth/exphelp/viewer/help/mobile-app-developers/content-modeling/content-classes-for-apps.md

On this page

Content classes for apps

This page is for app developers who turn content classes into screens and data models. It explains how to learn what a class contains, how to use classIdentifier in the app, and how to stay robust when the site team changes a class.

Contents

  1. Learning the classes
  2. classIdentifier as the switch
  3. Surviving class changes
  4. Fields that help apps

Learning the classes

Three ways, from simplest to most complete:

WayHowNeeds
Read real contentGET /api/ezp/v2/content/node/<id>?ResponseGroups=Fields: every field with type and identifiercontent/read
Ask the site teamthe class definitions in Setup > Classes of the administrationan editor or administrator
Read the definitionexpclass::get::<identifier>, expclass::attributes::<identifier>, expclass::requiredAttributes::<identifier>the class policy, so use a developer account, not the app's

expclass::identifiers gives a light map of class ids, identifiers and names to any signed-in user. The class services are declared in extension/expservices/classes/content/expclassservices.php.

classIdentifier as the switch

Every node, object and list entry carries classIdentifier. Use it to choose the cell and the detail screen:

when (item.classIdentifier) {
    "article" -> ArticleCell
    "event"   -> EventCell
    "folder"  -> FolderCell (drill down with the list route)
    else      -> GenericCell (objectName only)
}

Always have the generic case: editors can place a class the app does not know in a folder it shows, and the app must not crash or hide the whole list because of it.

Surviving class changes

Administrators can add, remove and reorder fields and change classes while the app is in users' hands. To stay robust:

  • Read fields by identifier, never by position.
  • Treat every field as optional, even if the class marks it required; old content may predate the requirement.
  • Check type before parsing; skip a field whose type changed.
  • Agree with the site team that renaming or removing a field the app uses is announced, like an API change.
  • Add a test that reads one item of every class the app uses on a test installation and fails on unexpected types (A local test installation).

Fields that help apps

If the site team builds or extends classes with the app in mind, a few fields make an app simpler:

FieldWhy
A short teaser text (plain ezstring or eztext)rich text reaches REST as plain text; a dedicated teaser field is clean for list cells
One main image fieldone place for the cell image (Images in REST answers)
A stable identifier for app-relevant folders, as a remote identry points survive reinstalls (Node ids, remote ids and deep links)

How classes are designed is the site team's subject: Content classes for websites, Choosing datatypes.

Become an Exponential Partner

Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.

Something wrong on this page? Report an error

Documentation license

This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.

Exponential Copyright © 1998-2026 Exponential Foundation and 7x