Appearance
Data Design
Data Design lets you create a visual layout for one item and populate that layout with different values from Project data. Use it when an application needs to display repeated content—such as product cards, customer profiles, or search results—without manually building a separate set of Page Elements for every record.
Data Design gives you control over how each item looks. The Page Elements define the layout and presentation, placeholders identify the content that can change, and Page Flow can supply data and render the resulting items into a visible area of the Page.
Common uses include:
- Product cards in a catalog.
- Search result tiles or custom result rows.
- Customer, member, or team profiles.
- Dashboard summary items.
- Event listings or other repeating content blocks.
- Record displays that need more visual flexibility than a standard table.
For a ready-made record-oriented table with built-in controls, see Data Table Widget.
How Data Design Works
Data Design brings together a reusable visual structure, dynamic values, and a destination for the rendered content.
| Concept | Purpose |
|---|---|
| Data Design | Defines the visual pattern for one item that can be rendered repeatedly. |
| Page Elements | Provide the item's layout, text, images, cards, buttons, links, and other supported content. |
| Placeholders | Identify values or element properties that should be populated from data when the design is rendered. |
| Project Data | Supplies the values used for each item, through supported data operations or application logic. |
| Rendering and Target Area | Creates visible content from the design and supplied data, then places that content in a designated area of the Page. |
For example, an application can define one product-card design containing an image, name, price, availability status, and View Details button. Page Flow can then use product records to render multiple cards from that one design.
The relationship is:
text
Data Design (one item)
Card
Image → Product image
Heading → Product name
Text → Price
Badge → Availability
Button → View details
+
Project data supplied through Page Flow
↓
Rendered items in a Page target area
Product card 1
Product card 2
Product card 3
...The same design can produce one item, many items, or no items, depending on the data and the application workflow.
A Data Design is the source pattern, not the finished list of records. Simply adding a Data Design to the Page does not automatically retrieve records or display repeated items. The appropriate rendering workflow must supply the values and place the results into the Page.
Designing One Repeated Item
Build the Data Design as though you were designing a single example of the content users should see.
For a product card, you might use:
- A Card or Container for the overall structure.
- An Image for the product photo.
- A Heading for the product name.
- Text for the price and short description.
- A Badge for stock or availability information.
- A Button or Link for a details action.
Some content may remain the same for every item, such as a static label. Other values, such as the image, name, and price, can be defined as placeholders and supplied from data when rendered.
Use meaningful element names for controls that Page Flow or other supported behavior needs to reference. Element names and dynamic placeholders serve related but different purposes: an element name identifies an element for editing or interaction; a placeholder identifies content to populate during rendering.
For more about building the visual structure, see Creating Data Design. For dynamic values, see Placeholders.
When to Use Data Design
Choose Data Design when:
- Multiple records or items should share the same visual layout.
- Each item should display values from Project data.
- The presentation needs images, badges, custom formatting, links, or other combinations of Page Elements.
- A card, tile, profile block, or custom row communicates the information better than ordinary table columns.
- You want to maintain one visual pattern instead of many individually configured copies.
Data Design vs. Tables and Cards
| Requirement | Recommended Approach |
|---|---|
| Fixed comparison content or a manually maintained reference table | Basic Table |
| A few static or manually edited cards | Cards |
| Project records in a standard table interface with built-in table controls | Data Table Widget |
| Repeated custom cards, tiles, profiles, or result rows populated from data | Data Design |
For example, a small team page with four manually maintained profiles may only need Cards. A directory that displays many profiles from Project records is a stronger candidate for Data Design.
A Data Design does not automatically provide the Data Table Widget's built-in search, pagination, or record-action controls. If a custom presentation needs filtering, navigation, or other interactions, configure the supported behavior separately through Page Flow and related Project capabilities.
Typical Workflow
A common Data Design implementation follows these steps:
- Add a Data Design. Open the Page in the Page Editor and add Data Design from the Dynamic Content area of the Element Library.
- Build one item. Arrange the Page Elements that define the repeated layout.
- Identify dynamic values. Configure placeholders for the content that should differ from one item to another.
- Choose a target area. Prepare the Page section, Container, Column, or other supported area where the rendered content should appear.
- Supply data and render. Use supported Page Flow operations to obtain the required values, populate the design, and place the rendered items in the target area.
- Add interactions as needed. Coordinate Buttons, Links, or other supported actions with the appropriate Page Flow and Backend behavior.
- Save and preview. Test the finished layout and behavior with realistic data at desktop, tablet, and mobile widths.
The detailed instructions are divided among Creating Data Design, Placeholders, and Rendering Data Design.
Data Design and Page Flow
Page Flow provides browser-side application logic that can coordinate data retrieval, rendering, and interactions with the content produced by a Data Design.
For example, a product catalog Page might:
- Retrieve the records that the current visitor is permitted to access.
- Use each record's product name, image, price, and status to populate the Data Design placeholders.
- Render the resulting product cards into the catalog's target area.
- Refresh the displayed results when the visitor changes a filter or searches, if that behavior has been configured.
- Handle a View Details action for a selected item.
The Data Design defines the visual pattern. Page Flow determines when data is obtained, what records are used, and how the rendered content participates in the Page's workflow.
Page Flow can use supported Project data interfaces, and it can invoke Cloud Flow when trusted server-side processing is required. Rendering content in the browser does not replace Project Database access rules or Backend authorization. Only retrieve and display data the visitor is permitted to access, and enforce protected actions through the appropriate Backend capabilities.
For details about constructing the runtime workflow, see Rendering Data Design and Page Flow.
Layout and Responsive Design
The Data Design controls the appearance of an individual item. The surrounding target area and Page layout determine where repeated items appear and how they are arranged.
For example, the same product-card design might be presented in a multi-column catalog or a narrower list, depending on how the target area is configured. Do not assume that the Data Design automatically creates a grid, changes the number of columns, or stacks items for smaller screens.
When designing for repetition:
- Keep each item readable with short, long, and missing values.
- Choose image sizing and text spacing that work across the expected range of records.
- Allow enough room for Buttons, Links, and other interactive elements.
- Use supported Layout Elements and responsive settings for the surrounding arrangement.
- Preview the rendered results at desktop, tablet, and mobile widths.
Previewing and Testing
Test the complete data-to-display workflow rather than only the design with example content.
Review these cases:
| Test Case | What to Check |
|---|---|
| No records | The Page handles an empty result appropriately instead of implying that data failed to load. |
| One record | The item appears in the intended target area without awkward layout or spacing. |
| Many records | Repeated items remain readable and the Page layout remains usable. |
| Missing values | Empty descriptions, absent images, or other missing fields do not create confusing content. |
| Long values | Names, descriptions, and labels wrap or fit acceptably. |
| Interactive items | Buttons, Links, and associated Page Flow actions operate on the intended item. |
| Different screen sizes | The rendered layout works at desktop, tablet, and mobile widths. |
Saving changes in the Page Editor does not automatically publish them. Use Preview to test the development version, then follow the Project publishing workflow when the changes are ready for visitors.
In This Section
The Data Design documentation is organized into three implementation topics:
| Topic | What You Will Learn |
|---|---|
| Creating Data Design | Add a Data Design, build the layout for one item, and prepare a target area for repeated content. |
| Placeholders | Identify the values that should change and prepare elements for dynamic population. |
| Rendering Data Design | Use Page Flow and supplied data to produce visible items in a Page area. |
Good Practices
- Design one item first. Build and validate the pattern before rendering it repeatedly.
- Keep the design focused. Use one Data Design for one consistent type of repeated content.
- Separate fixed and dynamic content. Use placeholders only for values that need to change.
- Use meaningful names. Name elements and placeholders so their purpose is clear during maintenance.
- Choose the right display component. Use Data Table Widget for standard record tables and Data Design for custom repeated layouts.
- Plan the target layout. Design the repeated-item arrangement as well as the individual item.
- Test actual data. Preview empty results, missing fields, long values, and different record counts.
Common Mistakes
Avoid these patterns:
- Expecting a Data Design to fetch records or render visible items just because it was added to a Page.
- Building a complete collection of cards inside the Data Design instead of defining one repeated item.
- Confusing an element's editing name with the placeholder used to populate a dynamic value.
- Placing rendered content without planning the destination area or its responsive layout.
- Repeating manually created Cards when one Data Design could represent data-driven items.
- Assuming that search, pagination, and record actions are automatically supplied by Data Design.
- Using browser-side filtering, hidden controls, or visual layout as a substitute for Database permissions and Backend authorization.
- Testing only one ideal record before publishing.
Data Design is most useful when one visual pattern needs to become many data-driven items. Keep the design, the data, and the rendering workflow distinct so each can be configured and maintained appropriately.
Technical Reference
Use the Programming Guide for exact block names, inputs, and client API signatures; use this product guide for workflow, concepts, and authoring guidance.