**TITLE**: Filter Fields — Add, Configure, Move, Delete, and Maintain for Fiori List Report

**INTRODUCTION**: This guide provides concise, action-oriented instructions and minimal annotation examples for implementing filter fields (compact filters and visual filters) in SAP Fiori list reports. Use these steps to: add/remove filter fields, add visual filters (charts), update or generate local annotations, and maintain filter/visual-filter properties. Relevant files: local annotation file (annotations XML) and manifest.json.

**TAGS**: fiori-tools, annotations, UI.SelectionFields, UI.Chart, UI.PresentationVariant, Common.ValueList, manifest.json, CAP, analytics

STEP: Add a Filter Field
DESCRIPTION: Add a compact filter (filter field with value help) to the Filter Bar of a list report. This generates or updates the UI.SelectionFields annotation in your local annotation file. Note blocked properties: properties annotated with UI.Hidden, UI.HiddenFilter, or listed as NonFilterableProperties in Capabilities.FilterRestrictions are not available.
LANGUAGE: UI/Manual
CODE:
```html
<!-- Optional stylesheet reference used in docs -->
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: Add a Filter Field — Actions
DESCRIPTION: UI actions to perform in the Fiori Tools Page Map:
- Open Page Map for the list report page.
- Click Configure Page (pencil icon).
- Click Add (+) next to Filter Bar > Filter Fields.
- Search/select properties and click Add.
- Result: local annotation file is created/updated with UI.SelectionFields entries referencing the selected property paths.
LANGUAGE: None
CODE:
```text
Files touched:
- Local annotation file (e.g., annotations.xml or annotations.local.xml)
- manifest.json (control configuration updated if visual filter added)
```

STEP: UI.SelectionFields — Example Annotation
DESCRIPTION: Example XML fragment showing UI.SelectionFields with ordered PropertyPath elements. The sequence here controls filter sequence in runtime.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="MyService.MyEntityType">
  <Annotation Term="UI.SelectionFields">
    <Collection>
      <PropertyPath>PropertyA</PropertyPath>
      <PropertyPath>PropertyB</PropertyPath>
      <PropertyPath>PropertyC</PropertyPath>
    </Collection>
  </Annotation>
</Annotations>
```

STEP: Add a Visual Filter (analytics-enabled service)
DESCRIPTION: Add a visual filter (bar or line chart) using an analytically enabled entity. Workflow:
- Open Page Map -> Configure Page -> Add -> Filter Bar > Filter Fields.
- If analytics enabled and no visuals present, choose Add Visual Filters.
- Select the time-based or other property; choose chart type (bar or line for time-based; only bar for others).
- Select analytically enabled entity (value source), groupable property (dimension), and choose/create measure (aggregated property or existing measure).
- Click Add. This generates UI.Chart, UI.PresentationVariant, Common.ValueList annotations and references UI.SelectionFields. manifest.json is updated with control configuration referencing the value list/presentation variant.
LANGUAGE: Manual/Annotations
CODE:
```xml
<!-- Example generated annotations (minimal) -->
<Annotations Target="MyService.AnalyticEntity">
  <!-- Chart based on chosen dimension and measure -->
  <Annotation Term="UI.Chart" Qualifier="MyVisualFilter">
    <Record>
      <PropertyValue Property="Dimensions">
        <Collection>
          <Record>
            <PropertyValue Property="Value" Path="DimensionProperty"/>
          </Record>
        </Collection>
      </PropertyValue>
      <PropertyValue Property="Measures">
        <Collection>
          <Record>
            <PropertyValue Property="Value" Path="MeasureProperty"/>
          </Record>
        </Collection>
      </PropertyValue>
    </Record>
  </Annotation>

  <!-- PresentationVariant referencing the chart -->
  <Annotation Term="UI.PresentationVariant" Qualifier="MyVisualFilter">
    <Record>
      <PropertyValue Property="Visualizations">
        <Collection>
          <AnnotationPath>@UI.Chart#MyVisualFilter</AnnotationPath>
        </Collection>
      </PropertyValue>
    </Record>
  </Annotation>
</Annotations>

<!-- Common.ValueList referencing presentation variant via qualifier (example reference) -->
<!-- UI.SelectionFields updated separately to include the compact filter property -->
```

STEP: Visual Filter — Measure Creation Rules
DESCRIPTION: When creating a new measure for visual filter charts:
- You may create a measure based on an aggregable property and supported aggregation (if no existing measure with same combo exists).
- Custom aggregation-based properties for measures are not supported for new measures.
- If using existing measures, select one defined with custom or transformation aggregations.
LANGUAGE: Manual
CODE:
```text
Notes:
- New measure allowed only if no existing measure uses same value source + aggregation.
- Transformation-aggregated measures update Common.Label on Analytics.AggregatedProperty.
```

STEP: Moving Filter Fields (change filter order)
DESCRIPTION: Change compact filter order to adjust runtime filter sequence and visual filter sequence (visual filters follow compact filter order when compact filter for same property exists).
Options:
- Drag & drop Filter Fields in Page Map.
- Use Move Up / Move Down icons.
- Keyboard: focus Move Up/Down and press Enter.
Effect: Reorder PropertyPath entries in UI.SelectionFields; update local annotation file with new sequence.
LANGUAGE: XML
CODE:
```xml
<!-- Example: reorder UI.SelectionFields collection to reflect new order -->
<Annotation Term="UI.SelectionFields">
  <Collection>
    <PropertyPath>PropertyB</PropertyPath> <!-- moved up -->
    <PropertyPath>PropertyA</PropertyPath>
    <PropertyPath>PropertyC</PropertyPath>
  </Collection>
</Annotation>
```

STEP: Deleting a Filter Field
DESCRIPTION: Delete a filter field from the Filter Fields list:
- Select filter field in Page Map outline.
- Click Delete (trash icon).
Effects:
- PropertyPath entry removed from UI.SelectionFields in local annotation file.
- Common.Label annotations are NOT removed automatically (may be reused elsewhere).
- For visual filters: deleting the visual filter removes manifest.json control configuration; local annotations remain until you run Remove Unused Local Annotations.
LANGUAGE: Manual / XML
CODE:
```text
Files to update:
- local annotation file: remove corresponding <PropertyPath> entry from UI.SelectionFields collection.
- manifest.json: control configuration entry for the visual filter removed.
```

STEP: Maintain Filter Field Properties
DESCRIPTION: Editable compact filter properties include Label, External ID, Text, Text Arrangement, Display Type. Visual filter-specific properties include Measure Label, Dimension Label, Dimension Text/Arrangement, Measures/Currencies, Scale Factor, Number of Fractional Digits, Sort Order, Fixed Values (filters).
Actions to change label globally:
- In Page Map outline click Filter Fields.
- Edit Label in Property Panel.
Notes:
- Removing label text does not delete existing @title or Common.Label annotations in upper/lower layers.
- Changing a label affects all occurrences unless overridden.
LANGUAGE: Manual/XML
CODE:
```xml
<!-- Example: Common.Label applied to a property -->
<Annotations Target="MyService.MyEntityType/PropertyA">
  <Annotation Term="Common.Label" String="New Label for PropertyA"/>
</Annotations>
```

STEP: Measure & Dimension Labels, Scale Factor, Fractional Digits, Sort Order
DESCRIPTION:
- Change Measure/Dimension labels in the Filter Property Panel (Measures/Dimensions table > Label column). If no label defined, property name is shown.
- Scale Factor: default automatic; explicit values selectable. Scale factor is defined in UI.DataPoint referenced from UI.Chart.
- Number of fractional digits: set 0/1/2; for currency measures decimals respected only when scale factor defined.
- Sort Order: Add Sort Property (defaults to ascending), change to Descending to invert. Sorting not supported for line charts or bar charts using other property sorting.
LANGUAGE: XML/Manual
CODE:
```xml
<!-- Example: UI.DataPoint referenced by UI.Chart to define scaling/format -->
<Annotation Term="UI.DataPoint" Qualifier="MyVisualFilter">
  <Record>
    <PropertyValue Property="Value" Path="MeasureProperty"/>
    <PropertyValue Property="Scaling">
      <Record>
        <PropertyValue Property="Factor" String="1000"/> <!-- example scale factor -->
      </Record>
    </PropertyValue>
    <PropertyValue Property="NumberOfFractionalDigits" Int="2"/>
  </Record>
</Annotation>
```

STEP: Fixed Values (limit visual filter data)
DESCRIPTION: Limit visual filter data by adding one or more fixed filters:
- Click Add Filters in Property Panel for the visual filter.
- Default suggested property is the dimension; you may change to any numeric, string, or Boolean property of the visual filter entity.
- For each filter define: Include/Exclude, Comparison Operator, Value (or Low/High for Between/Not Between).
Notes:
- Value defaults to empty string; update to matching values or chart shows no data.
- Filters are applied to the chart and restrict the bars shown.
- You can reorder filters (drag & drop or Move Up/Down) and delete individual filters (trash icon).
LANGUAGE: Manual
CODE:
```text
Filter definition elements:
- Include/Exclude: boolean flag
- Operator: EQ, NE, GT, LT, Between, NotBetween, etc.
- Value: single value or Low Value + High Value for range operators
```

STEP: CAP Node.js Note (analytics)
DESCRIPTION: If using CAP Node.js, some analytical features depend on the OData parser. Verify compatibility per CAP release notes.
LANGUAGE: Manual/Link
CODE:
```text
Reference:
https://cap.cloud.sap/docs/releases/oct22?q=odata_new_parser#alp-sflight
```


**TITLE**: Footer Actions for Object Page (Fiori Tools)

**INTRODUCTION**: This doc explains how footer actions on an Object Page are determined, constrained, maintained, and moved. It is targeted at code-generation agents and developers implementing UI annotations for actions on the page footer. Use these steps to locate, add, update, or relocate footer actions in your CDS/annotation-based metadata.

**TAGS**: fiori-tools, annotations, UI.DataFieldForAction, UI.Identification, footer, object-page, actions, CDS

**STEP**: 1 — Identify Footer Actions

**DESCRIPTION**: Footer actions are created from UI.DataFieldForAction records that are referenced in the UI.Identification annotation applied to the main entity of the page. Only those actions that are part of the UI.Identification and have Determining set to true are shown in the Footer.

- Check the main entity's UI.Identification annotation for Data entries containing $Type: "UI.DataFieldForAction".
- Confirm the containing UI.Identification object has Determining: true.

**LANGUAGE**: CDS

**CODE**:
```CDS
// Example (pseudocode): UI.DataFieldForAction inside UI.Identification must be present
annotate MyService.MyEntity with {
  @UI.Identification: [
    {
      Determining: true,
      Data: [
        { $Type: "UI.DataFieldForAction", Action: "Approve" },
        { $Type: "UI.DataFieldForAction", Action: "Reject" }
      ]
    }
  ]
};
```

**STEP**: 2 — Restriction: External Navigation Actions

**DESCRIPTION**: External navigation actions are not allowed in the Footer regardless of the Determining value. Before adding an action to the footer, verify it is not an external navigation action.

**LANGUAGE**: Text

**CODE**:
```Text
// Rule: External navigation actions cannot be shown in the Footer.
// If Action is external navigation, remove or relocate it (header or other UI areas if allowed).
```

**STEP**: 3 — Add / Delete / Maintain Footer Actions

**DESCRIPTION**: Manage footer actions the same way you manage table actions based on UI.DataFieldForAction. Use the same annotation patterns and tooling described in the Table Actions documentation.

- Follow the procedures in: table-actions-da1931b.md
- When adding a new action, ensure it is referenced in UI.Identification (see Step 1) so it can appear in the Footer.

**LANGUAGE**: Text

**CODE**:
```Text
// Reference: Use the same patterns and tooling as described in
// table-actions-da1931b.md to add/delete/maintain actions.
```

**STEP**: 4 — Annotation Properties and Their Effects

**DESCRIPTION**:
- Importance and RequiresContext: These properties are not relevant for header actions (i.e., they do not affect whether an action appears in the Footer/header).
- Criticality: This property influences the ordering of actions in the Object Page footer. Changing Criticality from None to Positive/Negative (or vice versa) automatically updates the action sequence in the Page Editor outline view.

**LANGUAGE**: Text

**CODE**:
```Text
// Notes:
// - @UI.Importance and @UI.RequiresContext: irrelevant for header/footer determination.
// - @UI.Criticality: changing value will reorder actions in the Page Editor outline.
```

**STEP**: 5 — Moving Actions Between Footer, Header, and Form Sections

**DESCRIPTION**: Actions can be relocated between the Footer, page header, and Form sections that are bound to the main entity. Ensure the action is not semantically highlighted; semantically highlighted actions cannot be moved.

- You may move any non-semantic actions from Footer to header or to Form sections based on the main entity.
- Verify the UI annotations after moving (UI.Identification and target UI areas) so the action appears in the intended location.

**LANGUAGE**: Text

**CODE**:
```Text
// Move rules:
// - Allowed: Footer <-> Header, Footer <-> Form sections (if action is not semantically highlighted)
// - Not allowed: Moving semantically highlighted actions
// After moving, update annotations (e.g., UI.Identification, target area) accordingly.
```

fiori-tools annotations UI.DataFieldForAction UI.Identification footer object-page actions CDS


**TITLE**: Form and Object Page — Fiori Tools Reference and Implementation Skeleton

**INTRODUCTION**: This document summarizes the supported elements for a Fiori Form and Object Page and provides a concise, action-oriented implementation skeleton for code generation tools. Use the skeleton to scaffold an SAPUI5 Object Page view and replace placeholders with your actual fragments, form controls, and tables. Links to detailed element docs and SAP Design Guidelines are included for reference.

**TAGS**: fiori-tools, object-page, form, UI5, SAP Fiori, uxap, ObjectPageLayout

STEP: 1 — Purpose and Design Reference

DESCRIPTION: Use the SAP Design Guidelines to align layout and behavior of the Object Page with Fiori UX standards. Follow the linked guideline for general rules on header, sections, responsiveness, and behavior.

LANGUAGE: URL/Reference

CODE:
```text
SAP Design Guidelines (Object Page):
https://experience.sap.com/fiori-design-web/object-page/
```

STEP: 2 — Supported Elements (links to detailed docs)

DESCRIPTION: These are the supported elements you can include in the Form and Object Page. For each element, open the linked document to get element-specific properties, recommended patterns, and code examples. Use consistent IDs and binding paths across header, sections, and footer.

LANGUAGE: Markdown/Links

CODE:
```text
Supported elements of the Form and Object Page:
- Header:
  - link: header-a05d7fc.md#loioa05d7fc1bbbf42a0ade9fb50f6b58b56
- Form Section:
  - link: form-section-4102b3d.md
- Table Section:
  - link: table-section-fc59378.md
- Identification Section:
  - link: identification-section-b83f501.md
- Group Section:
  - link: group-section-1894c47.md
- Footer:
  - link: footer-1b391bd.md
```

STEP: 3 — Object Page XML View Skeleton (SAPUI5)

DESCRIPTION: Scaffold an Object Page view using sap.uxap.ObjectPageLayout. Replace placeholders (/* ... */) and fragment includes with your generated fragments / controls. Keep binding contexts consistent between header, sections, and footer.

LANGUAGE: XML

CODE:
```xml
<!-- File: view/ObjectPage.view.xml -->
<mvc:View
  controllerName="my.app.controller.ObjectPage"
  xmlns:mvc="sap.ui.core.mvc"
  xmlns="sap.m"
  xmlns:uxap="sap.uxap">
  <uxap:ObjectPageLayout
    id="objectPage"
    showTitleInHeaderContent="true"
    headerContent="{/HeaderModel}">
    <!-- Header / Object Header -->
    <uxap:headerContent>
      <!-- Example ObjectHeader; replace with your objectHeader fragment or controls -->
      <ObjectHeader
        id="objectHeader"
        title="{HeaderModel>/title}"
        number="{HeaderModel>/number}"
        intro="{HeaderModel>/intro}">
        <!-- Add attributes/markers/actions as needed -->
      </ObjectHeader>
    </uxap:headerContent>

    <!-- Sections -->
    <uxap:sections>

      <!-- Identification Section -->
      <uxap:ObjectPageSection id="identificationSection" title="Identification">
        <uxap:ObjectPageSubSection id="identSubSection">
          <!-- Use a Form fragment or controls for identification fields -->
          <Form id="identForm">
            <layoutData>
              <ResponsiveGridLayout />
            </layoutData>
            <FormContainer>
              <FormElement>
                <Label text="ID" />
                <Input value="{/Entity/ID}" />
              </FormElement>
              <FormElement>
                <Label text="Name" />
                <Input value="{/Entity/Name}" />
              </FormElement>
            </FormContainer>
          </Form>
        </uxap:ObjectPageSubSection>
      </uxap:ObjectPageSection>

      <!-- Group/Form Section -->
      <uxap:ObjectPageSection id="formSection" title="Form Section">
        <uxap:ObjectPageSubSection id="formSubSection">
          <!-- Replace with generated Form Section fragment -->
          <Form id="mainForm">
            <FormContainer>
              <FormElement>
                <Label text="Field 1" />
                <Input value="{/Entity/Field1}" />
              </FormElement>
              <FormElement>
                <Label text="Field 2" />
                <Input value="{/Entity/Field2}" />
              </FormElement>
            </FormContainer>
          </Form>
        </uxap:ObjectPageSubSection>
      </uxap:ObjectPageSection>

      <!-- Table Section -->
      <uxap:ObjectPageSection id="tableSection" title="Related Items">
        <uxap:ObjectPageSubSection id="tableSubSection">
          <!-- Replace with your Table fragment or a sap.m.Table / sap.ui.table.Table -->
          <Table id="itemsTable" inset="false" items="{/Entity/Items}">
            <headerToolbar>
              <Toolbar>
                <Title text="Items" />
                <!-- Add actions, search, filters as needed -->
              </Toolbar>
            </headerToolbar>
            <columns>
              <Column>
                <Text text="Item ID" />
              </Column>
              <Column>
                <Text text="Description" />
              </Column>
            </columns>
            <items>
              <ColumnListItem>
                <cells>
                  <Text text="{ID}" />
                  <Text text="{Description}" />
                </cells>
              </ColumnListItem>
            </items>
          </Table>
        </uxap:ObjectPageSubSection>
      </uxap:ObjectPageSection>

    </uxap:sections>

    <!-- Footer -->
    <uxap:footer>
      <!-- Replace with footer fragment or controls (e.g., actions, Save/Cancel) -->
      <OverflowToolbar id="objectFooter">
        <ToolbarSpacer />
        <Button id="saveBtn" text="Save" press="onSave" />
        <Button id="cancelBtn" text="Cancel" press="onCancel" />
      </OverflowToolbar>
    </uxap:footer>
  </uxap:ObjectPageLayout>
</mvc:View>
```

STEP: 4 — Controller Hooks and Binding Tips

DESCRIPTION: Implement controller hooks for actions, navigation, and lifecycle. Bind models at component/route level and ensure the Object Page's context is set before opening (e.g., setBindingContext or bindElement). Use stable IDs and follow accessibility labels.

LANGUAGE: JavaScript

CODE:
```javascript
// File: controller/ObjectPage.controller.js
sap.ui.define([
  "sap/ui/core/mvc/Controller"
], function (Controller) {
  "use strict";
  return Controller.extend("my.app.controller.ObjectPage", {
    onInit: function () {
      // Example: set model or wait for route match to bind context
      // this.getView().setModel(this.getOwnerComponent().getModel("entityModel"));
    },
    onSave: function () {
      // Implement save logic, validations, and model submit
    },
    onCancel: function () {
      // Implement navigation back or reset changes
    }
  });
});
```

STEP: 5 — Implementation Checklist

DESCRIPTION: Use this checklist while generating code:
- Ensure header, sections, and footer anchors/IDs are unique.
- Keep model binding paths consistent across header and sections.
- Replace placeholder fragments with generated fragments for Form, Table, Group, and Identification sections.
- Use SAP Design Guidelines for responsive behavior and accessible labels.
- Add actions in header/footer as required (e.g., Edit, Save, Delete) and wire controller event handlers.

LANGUAGE: Checklist

CODE:
```text
Implementation Checklist:
- Unique IDs for ObjectPageLayout, sections, subsections, controls.
- Bind view to the entity model before rendering (bindElement or setBindingContext).
- Replace placeholder Form/Table fragments with generated sections from templates.
- Wire controller methods for onSave, onCancel, navigation, and routing.
- Validate fields and handle message/toast patterns for errors/success states.
```

fiori-tools
object-page
form
UI5
SAP Fiori
uxap
ObjectPageLayout


**TITLE**: Form Section — Add, Move, Delete, and Maintain UI.FieldGroup / UI.ReferenceFacet Annotations

**INTRODUCTION**: This doc specifies the exact UI actions and annotation side-effects when working with Form Sections in the Fiori Tools Page Editor. Use these steps to implement UI changes and to update or verify underlying annotation files (UI.FieldGroup, UI.ReferenceFacet, UI.Facet). It includes UI steps, expected annotation modifications, multi-select and drag/drop behavior, deletion cleanup, and property behavior (Label, Display On Demand, Hidden).

**TAGS**: fiori-tools, Fiori, annotations, UI.FieldGroup, UI.ReferenceFacet, UI.Facet, Object Page, Form Section, i18n, CAP, CDS

STEP: Include SAP icons CSS (document header)
DESCRIPTION: Add the SAP icons stylesheet reference used by the editor previews and documentation.
LANGUAGE: HTML
CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: Add Form Section (UI steps)
DESCRIPTION: Use the Page Editor to add a new Form Section tab to an Object/Form Entry Page. The UI steps below produce annotation changes described in the following STEP.
LANGUAGE: text
CODE:
```
1. Open the Object/Form Entry Page in the Page Editor.
2. In the outline, select the section node and click the + (Add) icon.
   - A dropdown shows supported section types.
3. Choose "Add Form Section".
   - A pop-up "Add Form Section" appears with a Label field.
4. Enter the section title in Label and click Add.
   - If translation is needed, see Internationalization (i18n): internationalization-i18n-eb427f2.md
   - A new section tab appears in the application preview and Object Page. Add fields to the new section afterwards.
   - For adding fields: see Adding Filter Fields: filter-fields-0b84286.md#loio0b8428645243486680ffa22c0b541039__addingfilterfields
```

STEP: Annotation changes applied when adding a Form Section
DESCRIPTION: After adding a form section via the editor, the tool updates annotations. Confirm or implement the following changes in your annotation files. If UI.Facet was absent, it will be added; if present on a lower layer, it will be overridden locally. In CAP/CDS scenarios, a using statement may be added to the overridden file.
LANGUAGE: text
CODE:
```
- A new UI.FieldGroup is added with an empty Data property.
- A UI.ReferenceFacet record is added to the UI.Facets annotation with properties:
  - Target: an annotation path pointing to the created UI.FieldGroup
  - Label: string value containing the user-entered label
  - ID: string value auto-generated from the label
- If UI.Facet annotation is not present on the entity, it is applied to the entity associated with the Object Page.
- If UI.Facet exists on an underlying layer, the annotation on this layer will be overridden in the local file.
- In CAP CDS, a using statement is added to the overridden file when applicable.
```

STEP: Move Form Section (reorder header sections)
DESCRIPTION: Reorder header sections in the Page Editor by drag & drop. Reordering updates UI.Facets records sequence; the runtime reads UI.HeaderFacets sequence to render sections.
LANGUAGE: text
CODE:
```
- Drag and drop a section to change its position within Header Sections.
  - When dropped, records in UI.Facets are reordered to match the new sequence.
  - The SAP Fiori app renders sections using the record order in UI.HeaderFacets.

Move multiple sections:
1. Ctrl + Click to select multiple sections in the outline.
2. Drag the selected group and drop at the new position.
  - Multiple selected items are moved together and UI.Facets is reordered accordingly.
```

STEP: Delete Form Section
DESCRIPTION: Delete a Form Section node in the Page Editor. The editor removes the UI.ReferenceFacet record; unreferenced UI.FieldGroup annotations must be removed with a cleanup procedure.
LANGUAGE: text
CODE:
```
1. In the outline, select the section node.
2. Click the delete (wastebasket) icon.
3. Confirm in the Delete Confirmation pop-up by clicking Delete.

Notes:
- This action deletes the UI.ReferenceFacet record from UI.Facets.
- To remove the unreferenced UI.FieldGroup annotation, run the cleanup procedure to delete unreferenced annotations.
```

STEP: Maintain Form Section Properties — Label
DESCRIPTION: Update the section label through the Properties panel. This updates the Page Editor and application preview immediately.
LANGUAGE: text
CODE:
```
1. Select the section in the Page Editor.
2. In the Properties pane, change the Label text.
   - The label change updates both the Page Editor and the application preview.
   - See Label reference: appendix-457f2e9.md#loiod44832d99bdf4f73ba14cdbb16dc9301
```

STEP: Maintain Form Section Properties — Display On Demand
DESCRIPTION: When a Form Section or Identification Section is used as a subsection inside a Group Section, the Property Panel shows a Display On Demand toggle. Enable to hide this subsection under "Show More" by default; disable to always display. The editor records this as an embedded annotation on the UI.ReferenceFacet.
LANGUAGE: text
CODE:
```
- Default: Display On Demand is deactivated.
- When activated: an embedded annotation @UI.PartOfPreview with boolean false is added to the respective UI.ReferenceFacet record.
  Example embedded annotation entry (conceptual):
    "@UI.PartOfPreview": false
- When deactivated: the embedded annotation is removed.
- If the section is moved and no longer contained in a Group Section, the embedded annotation is removed.
- Applicable pages: Form Section (form-section-4102b3d.md) and Identification Section (identification-section-b83f501.md) when used inside Group Section (group-section-1894c47.md).
```

STEP: Maintain Form Section Properties — Hidden
DESCRIPTION: Hidden behavior is available in the Properties pane. Refer to the Hidden appendix for exact semantics and annotation patterns.
LANGUAGE: text
CODE:
```
- For implementation and annotation details, see Hidden: appendix-457f2e9.md#loiof7ad71792a0044d6b6172f078827bdc0
```


**TITLE**: Group Section — Add, Edit, Move, Delete (Fiori Tools, UI.Facets)

**INTRODUCTION**: This document summarizes actionable, code-oriented steps for working with Group Sections in Fiori Tools Page Editor. It describes the runtime annotation changes (UI.Facets / UI.CollectionFacet), UI actions (add, add subsection, move, delete), and how to edit resulting annotations in source code. Use these steps when generating code or automation that modifies page annotations or implements editor actions.

**TAGS**: fiori-tools, UI.Facets, UI.CollectionFacet, annotations, page-editor, group-section, i18n, edit-in-source

STEP: Include UI icon stylesheet (editor preview)
DESCRIPTION: Ensure the preview/editor includes the SAP icon stylesheet used by the Page Editor UI. This is the top-level static include used by the documentation preview.
LANGUAGE: HTML
CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: Add Group Section (UI: Page Editor action → annotation change)
DESCRIPTION: User action in Page Editor: open the Object or Form Entry Page, navigate to the section layer, click Add → Add Group Section, enter a Label and confirm. Programmatically, this inserts a new UI.CollectionFacet entry into the UI.Facets annotation. The new UI.CollectionFacet must include a Label and an empty Facets array. If UI.Facets does not exist, create it in the changeable annotation file.
LANGUAGE: UI Annotations (JSON example)
CODE:
```json
{
  "UI.Facets": [
    {
      "@type": "UI.CollectionFacet",
      "Label": { "String": "Group Title" },
      "Facets": []
    }
  ]
}
```

STEP: Add Group Section (UI Annotations XML example)
DESCRIPTION: Same as above but shown in XML annotation format — add a UI.CollectionFacet record with Label and an empty Facets collection.
LANGUAGE: XML
CODE:
```xml
<Annotations Target="YourService.YourEntityType">
  <Annotation Term="UI.Facets">
    <Collection>
      <Record Type="UI.CollectionFacet">
        <PropertyValue Property="Label">
          <String>Group Title</String>
        </PropertyValue>
        <PropertyValue Property="Facets">
          <Collection/>
        </PropertyValue>
      </Record>
    </Collection>
  </Annotation>
</Annotations>
```

STEP: Add Subsection inside a Group Section (editor action → annotation update)
DESCRIPTION: From the Page Editor, expand the Group Section, click Add under Subsections, choose a supported section type (e.g., Form Section), provide a Label, and confirm. Programmatically, append a facet entry to the parent UI.CollectionFacet.Facets array. The Facets array holds facet records (one per subsection). Use the editor’s "Edit in Source Code" for manual annotation edits or i18n keys for labels when required.
LANGUAGE: UI Annotations (JSON placeholder)
CODE:
```json
{
  "UI.Facets": [
    {
      "@type": "UI.CollectionFacet",
      "Label": { "String": "Group Title" },
      "Facets": [
        /* add facet objects here for each subsection, e.g. form section records */
      ]
    }
  ]
}
```

STEP: Subsection Form Section behavior (editor note)
DESCRIPTION: Once a Form Section is added as a subsection, you may perform all classic form-section operations (add/edit/move/delete fields). Use the Form Section documentation for field-level operations and the i18n workflow to prepare labels for translation.
LANGUAGE: None
CODE:
```text
Reference: See classic Form Section documentation for field operations and i18n label handling.
```

STEP: Move Sections (drag-and-drop behavior → annotation ordering)
DESCRIPTION: Sections inside a group can be reordered by drag-and-drop within the same group, between groups, or moved to the top level. The editor updates the Facets array ordering in UI.Facets to reflect the new structure. For automation, reorder entries in the Facets collection and persist the updated annotation file.
LANGUAGE: None
CODE:
```text
Action required: Reorder elements in UI.Facets[].Facets to match the new visual order.
```

STEP: Delete Group Section or Subsection (editor action → annotation removal)
DESCRIPTION: From the Page Editor, select the section and click Delete → confirm. This removes the corresponding UI.CollectionFacet record from UI.Facets (and its nested facet content). After deletion, run the annotation cleanup procedure to remove any unreferenced annotations left behind.
LANGUAGE: UI Annotations (JSON before / after example)
CODE:
```json
// Before deletion: UI.Facets contains the collection facet to be removed
{
  "UI.Facets": [
    {
      "@type": "UI.CollectionFacet",
      "Label": { "String": "Group Title" },
      "Facets": [ /* ... */ ]
    },
    { /* other facets */ }
  ]
}

// After deletion: remove the entire UI.CollectionFacet record for the deleted group
{
  "UI.Facets": [
    { /* other facets remain */ }
  ]
}
```

STEP: Cleanup unreferenced annotations (post-delete)
DESCRIPTION: After deleting a group section, ensure you invoke the project's annotation cleanup procedure/tool to remove any unreferenced annotations that belonged to the deleted section. This step prevents stale metadata from remaining in the changeable annotation file.
LANGUAGE: None
CODE:
```text
Action required: Run annotation cleanup to delete unreferenced annotation fragments after deletion.
```

STEP: Maintain Group Section Properties — Label
DESCRIPTION: To change the group section label via the editor: select the section, edit the Label field in the properties pane and confirm. Programmatically: update the Label property of the corresponding UI.CollectionFacet record. For translatable labels, replace the literal string with an i18n key and use the i18n file.
LANGUAGE: UI Annotations (JSON example)
CODE:
```json
{
  "UI.Facets": [
    {
      "@type": "UI.CollectionFacet",
      "Label": { "String": "New Group Title" }, // or use i18n key reference
      "Facets": []
    }
  ]
}
```

STEP: Maintain Group Section Properties — Hidden
DESCRIPTION: The editor supports a Hidden property for sections. To hide/show a group section, change the Hidden property in the properties pane. If editing annotations manually, set the appropriate annotation property (see platform-specific documentation for the exact annotation/term used to mark a section hidden).
LANGUAGE: None
CODE:
```text
Action required: Toggle the section's Hidden property in the editor or set the equivalent annotation flag in source.
```

STEP: Source edit & i18n references
DESCRIPTION: Use the Page Editor’s "Edit in Source Code" feature to jump to annotation fragments created/modified by these actions. Prepare label properties for translation following the project i18n workflow.
LANGUAGE: None
CODE:
```text
References:
- Defining and Adapting Sections: https://ui5.sap.com/#/topic/facfea09018d4376acaceddb7e3f03b6
- Internationalization (i18n): internationalization-i18n-eb427f2.md
- Edit in Source Code: edit-in-source-code-7d8e942.md
- Form Section reference: form-section-4102b3d.md
- Move Basic Fields: basic-fields-2953503.md#movebasicfields
```


**TITLE**: Object Page Header — Fiori Tools: properties, actions, sections, and micro-chart sorting

**INTRODUCTION**: Practical, code-focused guidance for configuring the Object Page header in SAP Fiori tools using annotation-driven properties. Covers UI.HeaderInfo mapping, header actions (standard, annotation-based, custom), adding/moving/deleting header sections, micro chart types and requirements, and how to enable sorting via PresentationVariant. Use these actionable annotation/manifest examples and property names when generating or modifying annotation files or manifest.json.

**TAGS**: fiori-tools, annotations, UI.HeaderInfo, UI.Facets, UI.HeaderFacets, UI.PresentationVariant, object-page, micro-chart, manifest.json

STEP: Add SAP icons stylesheet to project
DESCRIPTION: Include the SAP icons stylesheet (path shown in documentation) so icon URLs like sap-icon://accept render correctly in the UI.
LANGUAGE: HTML
CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: Set header annotation properties (UI.HeaderInfo)
DESCRIPTION: When any header property is set, create or update the UI.HeaderInfo annotation. Use these keys to control header content: TypeName, TypeNamePlural, Title, ImageUrl, Initials, TypeImageUrl. If UI.HeaderInfo is defined in a lower layer (service), the values show with a (base layer) suffix until changed locally.
LANGUAGE: JSON
CODE:
```json
"UI.HeaderInfo": {
  "TypeName": "MyType",                    /* displayed on top of object page */
  "TypeNamePlural": "MyTypes",             /* used as plural label (table header on list page) */
  "Title": { "Path": "MainTitleProperty" },/* choose entity property or set to None */
  "ImageUrl": { "Path": "ImageProperty" }, /* path to string property or 1:1 nav property */
  "Initials": { "Path": "InitialsProperty" },/* path to string property or 1:1 nav property */
  "TypeImageUrl": "sap-icon://accept"      /* SAP icon URL, example value shown */
}
```

STEP: Use Icon URL (TypeImageUrl) values
DESCRIPTION: Use SAP icon URLs for TypeImageUrl. Example format below — keep exact string format (sap-icon://<iconName>).
LANGUAGE: TEXT
CODE:
```
sap-icon://accept
```

STEP: Hide standard header actions (Edit/Delete) via annotations
DESCRIPTION: Hiding standard actions applies entity-set level annotations: UI.UpdateHidden for Edit and UI.DeleteHidden for Delete. Use boolean annotations on the entity set (or modify generated annotations) to control static hiding; for dynamic hiding use Hide by Property mapped to a boolean property.
LANGUAGE: JSON
CODE:
```json
/* Example: apply to the entity set annotations to hide buttons */
"EntitySetName": {
  "UI": {
    "UpdateHidden": true,   /* hides Edit */
    "DeleteHidden": true    /* hides Delete */
  }
}
```

STEP: Add annotation-based header actions
DESCRIPTION: Add header actions using UI.Identification records on the main entity:
- UI.DataFieldForAction (Determining = false or omitted) — in-app actions
- UI.DataFieldForIntentBasedNavigation — intent-based external navigation
- UI.DataFieldForActionGroups — action menus (use only annotation editor)
Keep in mind: Importance and RequiresContext are not relevant for header actions; Criticality affects action order in header; action menus do not support Criticality.
LANGUAGE: JSON
CODE:
```json
"UI.Identification": {
  "RecordType": "Collection",
  "Records": [
    { "RecordType": "UI.DataFieldForAction", "Label": "MyAction", "Action": "MyActionFunction" },
    { "RecordType": "UI.DataFieldForIntentBasedNavigation", "Label": "OpenApp", "SemanticObject": "TargetApp" },
    { "RecordType": "UI.DataFieldForActionGroups", "Actions": [ /* UI.DataFieldForAction records */ ] }
  ]
}
```

STEP: Add a header section (Page Editor workflow)
DESCRIPTION: Programmatic/authoring steps to create header sections (Form, Data Point, Progress, Rating, Micro Chart). Key constraints:
- Form: add fields manually after creating the section.
- Data Point: numeric/text; can set criticality and tooltip; optionally specify measure/currency.
- Progress: default target 100; set target type (constant/property) and criticality.
- Rating: default target 5; modify target in properties.
- Micro Chart: chart type (Area, Bullet, Column, Line, Radial, Comparison, Harvey, Stacked Bar) — many types require a 1:n navigation entity as Value Source.
After generation, properties are editable in Property Panel.
LANGUAGE: TEXT
CODE:
```
Steps (Page Editor):
1. Open Page Editor for object page.
2. Click Add (+) next to Header Sections.
3. Select section type and provide required fields:
   - Form: Label
   - Data Point / Progress / Rating: Value Source Property
   - Micro Chart: Chart Type -> if chart requires 1:n, select Value Source entity and measures/dimensions.
4. Save. Then edit generated properties in Property Panel as needed.
```

STEP: Header section facts: creation, movement, deletion and underlying annotations
DESCRIPTION: Annotations and effects to consider when adding/moving/deleting header sections:
- Adding/reordering sections updates the UI.Facets collection.
- At runtime the UI.HeaderFacets annotation sequence determines section rendering order.
- Moving sections in the editor reorders UI.Facets records.
- Deleting a section removes the UI.ReferenceFacet record from UI.Facets.
- Run the cleanup procedure afterward to remove unreferenced annotations (e.g., UI.FieldGroup, UI.PresentationVariant).
LANGUAGE: TEXT
CODE:
```
Annotation implications:
- UI.Facets: collection order reflects editor order
- UI.ReferenceFacet: each header section is referenced here; deletion removes this record
- UI.HeaderFacets: used by runtime to read header facet sequence
- Cleanup required to remove unreferenced UI.FieldGroup / UI.PresentationVariant entries
```

STEP: Micro chart types and Value Source constraints
DESCRIPTION: Summary of micro chart types, required source entities, and common properties:
- Area, Column, Line, Comparison, Stacked Bar: require a 1:n navigation entity as Value Source (measures and dimension from that entity).
- Bullet, Radial, Harvey: values may come from same entity or 1:1.
- Each chart type includes Label, Description, Hidden and chart-specific properties (Target Value, Dimension, Measures, Maximum/Minimum, Criticality Source, PresentationVariant reference).
LANGUAGE: TEXT
CODE:
```
Common requirement: For area/line/column/comparison/stacked-bar charts:
- Choose Value Source = 1:n associated entity
- Map measures and dimensions to properties of that entity
```

STEP: Enable micro chart sorting via PresentationVariant and manifest minUI5Version
DESCRIPTION: To sort micro chart data in header sections:
- Set Presentation Variant: Annotation to a UI.PresentationVariant annotation (choose New).
- In that PresentationVariant, define Sort Order entries (Property + Direction). Multiple sort properties can be ordered.
- Required: minUI5Version in manifest.json must be at least "1.130" to enable micro chart sorting.
LANGUAGE: JSON
CODE:
```json
/* manifest.json: ensure minUI5Version >= 1.130 */
{
  "sap.ui5": {
    "minUI5Version": "1.130"
  }
}

/* PresentationVariant skeleton with SortOrder entries referenced from micro chart header section */
"UI.PresentationVariant": {
  "Qualifier": "MyMicroChartPV",
  "SortOrder": [
    { "Property": "Date", "Descending": true },
    { "Property": "Value", "Descending": false }
  ]
}
```

STEP: PresentationVariant usage in Page Editor
DESCRIPTION: How to wire PresentationVariant to micro chart header section:
- Set Presentation Variant: Annotation to New to create a UI.PresentationVariant.
- Under Presentation Variant: Sort Order -> Add Sort Property -> choose Property and Direction.
- To remove sorting, set Presentation Variant: Annotation to None; run cleanup to remove unreferenced UI.PresentationVariant annotations.
LANGUAGE: TEXT
CODE:
```
PresentationVariant workflow:
1. Presentation Variant: Annotation = New (creates UI.PresentationVariant#Qualifier)
2. Under Sort Order -> Add Sort Property -> select Property and Direction
3. Reorder sort properties as necessary
4. To remove: Presentation Variant: Annotation = None, then run cleanup to remove unreferenced annotations
```

STEP: Cleanup after deletion or annotation changes
DESCRIPTION: After deleting sections or removing annotation references, run the annotation cleanup utility to remove unreferenced annotations (UI.FieldGroup, UI.PresentationVariant, etc.) so the annotation file stays clean.
LANGUAGE: TEXT
CODE:
```
Cleanup actions:
- Remove unreferenced UI.FieldGroup annotations
- Remove unreferenced UI.PresentationVariant annotations and qualifiers
- Ensure UI.Facets only contains active UI.ReferenceFacet entries
```


**TITLE**: Identification Section — Add / Move / Delete / Maintain (Fiori Tools)

**INTRODUCTION**: Short, actionable instructions for programmatic or UI-driven modifications of the Identification Section in a Fiori Elements Object/Form Entry Page. Explains how the editor operations map to annotation changes (UI.Identification, UI.Facets, UI.ReferenceFacet) and includes the relevant icon stylesheet reference.

**TAGS**: fiori-tools, UI.Identification, UI.Facets, UI.ReferenceFacet, i18n, drag-and-drop, page-editor, annotations

STEP: 1 — Add Identification Section

DESCRIPTION: Use the Page Editor to insert an Identification Section into an Object/Form Entry Page when UI.Identification is not yet defined or not referenced in UI.Facets. This action creates or references the UI.Identification annotation and updates UI.Facets accordingly. Identification sections cannot be subsections, cannot contain actions (use header/footer actions instead), and only one Identification Section may exist per page. You can provide a label prepared for translation (see i18n link).

- Editor actions:
  1. Open the Object/Form Entry Page in the Page Editor.
  2. In the outline, locate the section node and click the Add (+) icon.
  3. Select "Add Identification Section" from the dropdown.
  4. In the "Add Identification Section" popup, enter a Label and click Add.
- Resulting annotation behavior:
  - If UI.Identification does not exist: a UI.Identification annotation (no qualifier) is generated and referenced in UI.Facets.
  - If UI.Identification already exists: the existing UI.Identification is referenced in UI.Facets (no new UI.Identification generated).
- Translation: prepare the Label for translation (see internationalization-i18n-eb427f2.md).

LANGUAGE: HTML

CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: 2 — Move Identification Section

DESCRIPTION: Reorder sections in the Page Editor using drag-and-drop. The editor updates the UI.Facets collection to reflect the new order. The runtime Fiori application renders sections in the sequence defined by the records in UI.Facets.

- Single-section move:
  1. Drag the desired section node to the target position in the outline.
  2. Drop to update the UI.Facets order.
- Move multiple sections:
  1. Select multiple section nodes using Ctrl + Click.
  2. Drag the selected group and drop to the new position.
- Effect: When dropped, the editor reorders the records in UI.Facets; rendering follows the UI.Facets sequence.

LANGUAGE: Plaintext

CODE:
```text
Behavior mapping:
- Editor drag-and-drop -> updates UI.Facets record order
- Application rendering order = order of UI.Facets records
```

STEP: 3 — Delete Identification Section

DESCRIPTION: Remove the Identification Section from the page and update annotations.

- Editor actions:
  1. In the outline, select the Identification Section node.
  2. Click the Delete (wastebasket) icon to open the Delete Confirmation popup.
  3. Click Delete to confirm.
- Effect on annotations:
  - The Delete action removes the corresponding UI.ReferenceFacet record from the UI.Facets annotation.

LANGUAGE: Plaintext

CODE:
```text
Deletion result:
- Removed: corresponding UI.ReferenceFacet record in UI.Facets
- Note: This does not describe side effects to other annotations; verify UI.Identification usage if necessary.
```

STEP: 4 — Maintain Identification Section Properties — Label, Display on Demand, Hidden

DESCRIPTION: Modify properties of the Identification Section in the Page Editor properties pane.

- Change Label:
  1. Select the Identification Section.
  2. In the properties pane, update the Label text box.
  3. The new label is shown in the Page Editor outline and in the application preview.
  - Reference: appendix-457f2e9.md#loiod44832d99bdf4f73ba14cdbb16dc9301
- Display on Demand:
  - For behavior and configuration details see: form-section-4102b3d.md#loio4102b3d63d9047c881108e6f0caae15e__displayondemand
- Hidden:
  - For behavior and configuration details see: appendix-457f2e9.md#loiof7ad71792a0044d6b6172f078827bdc0

LANGUAGE: Plaintext

CODE:
```text
Property changes map:
- Label: updates visible section label and preview
- DisplayOnDemand: configure per form-section documentation
- Hidden: configure per appendix documentation
```


**TITLE**: Internationalization (i18n) — Configuration and UI Text Internationalization (Fiori Tools)

**INTRODUCTION**: Practical, code-focused guide for configuring i18n resource bundles and handling UI text internationalization actions in Fiori Tools. Use this to: (1) locate and configure i18n folder settings for non-CAP and CAP projects, (2) understand automated UI editor behavior when generating or referencing i18n keys, and (3) use mass i18n generation.

**TAGS**: fiori-tools, i18n, localization, CAP, manifest.json, .cdsrc.json, package.json, ui5

STEP: 1 — Configure i18n resource bundle folder

DESCRIPTION: Edit your project configuration to declare the resource bundle (i18n) folder(s). For non-CAP projects, configure /webapp/manifest.json. For CAP projects, configure either .cdsrc.json or package.json. CAP default folder list is provided below — use or modify this list in your CAP configuration.

LANGUAGE: JSON

CODE:
```json
["_i18n", "i18n", "assets/i18n"]
```

- Action: For non-CAP projects open /webapp/manifest.json and ensure the "sap.app" or i18n resourceBundle path points to your i18n folder.
- Action: For CAP projects open .cdsrc.json or package.json and update the i18n folder configuration; the default value is the array above.

STEP: 2 — Trigger i18n for a single UI text (editor behavior)

DESCRIPTION: In the Page Editor UI (properties pane or Add dialog), the Internationalization (i18n) icon appears next to translation-relevant input fields. Clicking it will perform one of three actions depending on the current state of the label/text. The editor prompts *Apply* or *Cancel*. The exact messages (presented to the user) are shown below and are replicated literally by the editor flow.

LANGUAGE: text

CODE:
```text
Generate a text key <uniquekey> in the i18n file and substitute <actual text> by {i18n>uniquekey}.
```

- When label is plain text and not yet internationalized: Apply generates a new i18n key and writes it to the i18n file, then substitutes the label value with a reference: {i18n>uniquekey}.

LANGUAGE: text

CODE:
```text
Generate a text key <uniqueKey> with value <uniquekey> in i18n file.
```

- When label is a reference to a text key but the key is missing in i18n files: Apply writes a new i18n entry using the key and a default value equal to the key.

LANGUAGE: text

CODE:
```text
Text key <uniqueKey> for value <sample text> is available in i18n file. Substitute <sample text> by {@i18n>uniqueKey}.
```

- When label is plain text but the text already exists in i18n: Apply substitutes the plain text with the existing i18n key reference: {@i18n>uniqueKey}.

STEP: 3 — Notes on key generation, annotation handling, and recommended workflow

DESCRIPTION: Preserve behavior and avoid surprises when the editor generates i18n keys and modifications across layers.

LANGUAGE: text

CODE:
```text
- i18n key casing: generated in camelCase for non-CAP projects and PascalCase for CAP projects.
- Repeated edits: the i18n icon creates a new entry for each new text to preserve history; this can create redundant keys.
```

- Annotation handling rules:
  - If a Field or Column label is defined directly on the property with @title or @Common.Label in a lower layer, the editor generates a Label property in the corresponding UI.DataField record referencing the i18n text in the resource bundle. Existing @title or @Common.Label annotations are not modified or overridden.
  - If a UI.FieldGroup or UI.Facet annotation is located in the lower layer, the editor copies that annotation to the application layer before creating or updating the Label reference.

- Recommended workflow: perform bulk i18n or finalize label texts near the end of development to prevent many redundant keys and reduce translation overhead.

STEP: 4 — Mass i18n creation (bulk generation)

DESCRIPTION: Use the Internationalization (mass i18n generation) icon at the top of the Page Editor to prepare multiple UI texts for translation in one operation.

LANGUAGE: text

CODE:
```text
- Action: Click the globe icon (mass i18n generation) to scan the page and generate i18n keys for multiple texts at once.
- Result: Multiple i18n entries are written to the configured i18n file(s), and UI labels are updated to reference those keys.
```

- Action steps: Open the Page Editor → click the mass i18n (globe) icon → review generated keys and Apply to write them to your resource bundle(s).

STEP: 5 — Practical references and file locations

DESCRIPTION: Quick reference for files and locations mentioned in configuration and behavior.

LANGUAGE: text

CODE:
```text
- Non-CAP projects: /webapp/manifest.json
- CAP projects: .cdsrc.json or package.json
- Default i18n folders (CAP): ["_i18n","i18n","assets/i18n"]
- i18n label substitution formats seen in the editor:
  - {i18n>uniquekey}
  - {@i18n>uniqueKey}
```


**TITLE**: Internationalization Support for XML Annotation Files (Annotation LSP)

**INTRODUCTION**: This guide explains how the XML Annotation Language Server (Annotation LSP) verifies and manages language-dependent strings in annotation files by using the i18n.properties file referenced from the @18n model in manifest.json. It covers verifying the project model, reusing existing text keys (Code Completion / Quick Fix), creating new keys (Quick Fix), and navigating to update translations (Go To / Peek Definition).

**TAGS**: fiori-tools, i18n, annotations, annotation-lsp, manifest.json, i18n.properties, Visual Studio Code, BAS, internationalization

STEP: Verify i18n model and properties file

DESCRIPTION: Ensure your app's manifest.json declares the @18n resource model and that the i18n properties file exists in the expected path. Annotation LSP will use the i18n bundle referenced by the @18n model in manifest.json. If the model or properties file is missing, Annotation LSP shows a warning in the annotation file.

LANGUAGE: JSON

CODE:
```json
{
  "sap.ui5": {
    "models": {
      "i18n": {
        "type": "sap.ui.model.resource.ResourceModel",
        "settings": {
          "bundleName": "i18n.i18n"
        }
      }
    }
  }
}
```

STEP: File path convention for properties

DESCRIPTION: Place the properties file in the project so it matches the bundleName above. Typical physical path (relative to webapp) is:
- webapp/i18n/i18n.properties

LANGUAGE: text

CODE:
```
/webapp/i18n/i18n.properties
```

STEP: Example UI (static) asset reference included in doc

DESCRIPTION: Preserve asset references required by project or tools. Example from documentation (CSS for icons):

LANGUAGE: HTML

CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: How Annotation LSP identifies language-dependent strings

DESCRIPTION: Annotation LSP checks annotation properties that are tagged as IsLanguageDependent in the vocabulary (for example, UI vocabulary: https://sap.github.io/odata-vocabularies/vocabularies/UI.html). Only properties with that tag are validated against the i18n.properties file. When you open an annotation file, every language-dependent string value is validated; missing or invalid references produce warnings and suggested Quick Fix actions.

LANGUAGE: text

CODE:
```
Reference: UI vocabulary (IsLanguageDependent)
https://sap.github.io/odata-vocabularies/vocabularies/UI.html
```

STEP: Reuse existing text keys — Code Completion

DESCRIPTION: While editing the string value of a language-dependent property in the annotation file, trigger Code Completion to list existing text keys and values from i18n.properties. Select a completion item to insert the referenced text key into the annotation string value.

LANGUAGE: text

CODE:
```
Trigger Code Completion:
- Windows: Ctrl + Space
- macOS: Cmd + Space

Behavior:
- Completion shows text-key references and text values from i18n.properties
- Selecting an item inserts the text key reference into the annotation file
```

STEP: Reuse or create text keys — Quick Fix actions

DESCRIPTION: When Annotation LSP detects a non-referenced or unmatched string value for a language-dependent property, it shows a warning and a Quick Fix (light bulb). Available Quick Fixes:
- Reuse an existing key: Insert a reference to an existing i18n key.
- Generate a new key: Create a new text key in i18n.properties with default attributes and substitute the annotation string with the new reference.

LANGUAGE: text

CODE:
```
Quick Fix:
- Click the light bulb icon next to the warning or use the editor Quick Fix command
- Choose either "Use existing text key" or "Create new text key"
Result:
- Existing key: annotation is updated to reference that key
- New key: i18n.properties receives a new entry and annotation is updated to reference it
```

STEP: Add a new language-dependent value manually

DESCRIPTION: Enter a string for the language-dependent property in the annotation file. If it's not present in i18n.properties, Annotation LSP issues a warning. Use Quick Fix to generate the i18n key and inject the reference automatically. After generation, you can edit the generated i18n.properties entry to add translations or comments.

LANGUAGE: text

CODE:
```
Workflow:
1. Edit annotation -> provide string for a language-dependent property
2. Annotation LSP warns if no matching i18n key exists
3. Invoke Quick Fix -> creates key in i18n.properties and replaces the annotation value with the reference
4. Open i18n.properties to update translations or add comments
```

STEP: Highlighting and fixing missing references at any time

DESCRIPTION: Open your annotation file. Annotation LSP highlights missing references with warnings. Apply Quick Fix to fix multiple occurrences as suggested (reuse or create keys). Use Code Completion to avoid warnings when inserting references.

LANGUAGE: text

CODE:
```
- Open annotation file -> warnings shown for missing i18n references
- Use Quick Fix (light bulb) to fix each missing reference or use Code Completion while editing
```

STEP: Navigate to or edit the i18n.properties entry from an annotation (Go To / Peek)

DESCRIPTION: Place the cursor inside the path referencing the translatable string value in the annotation file and use Go To Definition or Peek Definition to open or preview the i18n.properties entry. Use the appropriate editor keybindings or context menu.

LANGUAGE: text

CODE:
```
Go To Definition:
- VS Code: F12
- SAP Business Application Studio: Ctrl + F11
- Or: Ctrl + Click (Windows) / Cmd + Click (macOS)
Result: Opens the i18n.properties file at the referenced key

Peek Definition:
- VS Code: Alt + F12 (Windows) / Option + F12 (macOS)
- Or: Right-click -> Peek Definition
Result: Shows inline preview of the i18n.properties entry without leaving the annotation file
```

STEP: Tips for translators and additional attributes

DESCRIPTION: After Quick Fix generates a new i18n entry, open i18n.properties to:
- Add translation comments
- Add other attributes or metadata if required by your project tools
Use Go To / Peek Definition to jump from the annotation to the properties entry quickly.

LANGUAGE: text

CODE:
```
Post-generation actions:
- Open / edit / add translations in /webapp/i18n/i18n.properties
- Use Go To or Peek Definition from the annotation file to navigate
```

fiori-tools
i18n
annotations
annotation-lsp
manifest.json
i18n.properties
Visual Studio Code
BAS
internationalization


**TITLE**: List Report Page

**INTRODUCTION**: Brief overview and implementation pointers for generating a Fiori Elements List Report page. Use this when generating or scaffolding List Report pages to ensure inclusion of supported building blocks and to link to detailed design and implementation references.

**TAGS**: fiori-tools, list-report, fiori-elements, sap-fiori, ui5, floorplan

STEP: 1 - Fiori Design Guidelines (Overview)

DESCRIPTION: Reference the official Fiori Design Guidelines for the List Report floorplan. Use this link as the primary UX/design source when generating UI and when deciding which controls/behaviors to implement.

LANGUAGE: text

CODE:
```text
Fiori Design Guidelines: https://experience.sap.com/fiori-design-web/list-report-floorplan-sap-fiori-element/
Use this guideline for layout, expected behaviors, and UX details of the List Report floorplan.
```

STEP: 2 - Supported Elements (What to include)

DESCRIPTION: The List Report page supports a specific set of elements. When generating code, ensure the generated page scaffolding or annotations include these elements as required by the use case. For implementation details, follow each referenced file.

LANGUAGE: text

CODE:
```text
Supported elements (refer to the respective documentation files for implementation details):
- Filter Fields: filter-fields-0b84286.md
- Report Table: table-aaff7b1.md
- Multiple Views: multiple-views-c62b82e.md
- Analytical Chart: analytical-chart-9c086ec.md

Actionable note:
- For each element, consult the corresponding file above for attributes, required annotations, and example usage.
- Combine elements according to the floorplan: e.g., Filter Fields drive the Report Table and Analytical Chart; Multiple Views toggle between predefined table/chart configurations.
```

STEP: 3 - Generation Guidance (Actionable steps for code generators)

DESCRIPTION: Guidance checklist for code generators scaffolding a List Report page. Follow this sequence to produce a valid starting point and link to deeper files for each element.

LANGUAGE: text

CODE:
```text
Checklist for generators:
1. Add page entry/route for the List Report in the app manifest (or the framework-specific routing config).
2. Include the List Report template/component (framework-dependent) and map it to the target entity set.
3. Wire Filter Fields: reference annotation or descriptor file that defines filterable properties.
4. Scaffold Report Table: include columns, selection mode, and behaviors; consult table-aaff7b1.md for options (responsive table, grid table, analytical table).
5. Support Multiple Views: create view definitions and default view; consult multiple-views-c62b82e.md for view-switching patterns.
6. Optional Analytical Chart: include chart configuration and annotation mapping when analytics are required; see analytical-chart-9c086ec.md.
7. Validate generated page with the Fiori Design Guidelines URL for UX conformance.

Implementation tip:
- Keep element configuration modular so the generator can include/exclude Filter Fields, Table, Multiple Views, and Analytical Chart independently based on feature flags or input metadata.
- Point developers to the detailed docs listed in STEP 2 for property-level and annotation-level specifics.
```

List Report Page

fiori-tools list-report fiori-elements sap-fiori ui5 floorplan


**TITLE**: Maintaining Annotation-Based Elements in the Application Modeler

**INTRODUCTION**: This guide explains how the Application Modeler generates and maintains OData V4 annotation records when you add or modify UI elements (sections, fields) in the Page Editor. Use these steps when programmatically generating UI changes or writing tools that automate annotation updates for Fiori elements pages (list reports, object pages, form entry object pages).

**TAGS**: fiori-tools, annotations, UI.FieldGroup, UI.Facets, OData V4, Page Editor, Application Modeler

STEP: Preconditions and scope

DESCRIPTION: Confirm the Page Editor supports annotation generation. Annotation generation is available only for Page Editor pages that are:
- List reports
- Object pages
- Form entry object pages
All must be based on OData V4. If your page type or OData version is different, the automatic annotation generation features are not available.

LANGUAGE: Text

CODE:
```Text
Supported page types for annotation generation:
- List Reports (OData V4)
- Object Pages (OData V4)
- Form Entry Object Pages (OData V4)
```

STEP: Add a section (UI.FieldGroup) via the Application Modeler

DESCRIPTION: When you add a section in the Application Modeler (for Object Page or Form Entry Object Page) using the Sections node → Add (plus icon), the Page Editor will:
- Create a new UI.FieldGroup record representing the section.
- Ensure a UI.Facets annotation exists; if not, create UI.Facets.
- Add a reference to the new UI.FieldGroup inside the UI.Facets annotation.

Use this behavior when writing code to simulate or reproduce the add-section action: create a UI.FieldGroup entity and add its reference into UI.Facets.

LANGUAGE: Text

CODE:
```Text
Action performed by Application Modeler when adding a section:
1. Create UI.FieldGroup record (new section)
2. If UI.Facets does not exist -> create UI.Facets
3. Add reference to the UI.FieldGroup inside UI.Facets
```

STEP: Add fields to a section

DESCRIPTION: After a section (UI.FieldGroup) exists, adding fields via the Application Modeler will:
- Create field entries inside the UI.FieldGroup record.
- Update the local annotation file where UI.FieldGroup and UI.Facets are persisted.

When automating, ensure your code updates the UI.FieldGroup record to include the new fields and writes the updated annotations back to the local annotation file used by the project.

LANGUAGE: Text

CODE:
```Text
When adding fields to a section:
- Update the UI.FieldGroup record (add field entries)
- Persist updates to the project's local annotation file
```

STEP: Inspect and edit generated annotations in source

DESCRIPTION: Use the Page Editor's "Edit in Source Code" feature to view and manually edit the annotations that the Application Modeler generated. This is useful for fine-grained changes or for verifying the exact structure produced by the UI actions.

Refer to the built-in documentation page for details on the feature:
- edit-in-source-code-7d8e942.md

LANGUAGE: Text

CODE:
```Text
To view or edit annotations:
- Open "Edit in Source Code" in the Page Editor
- File containing generated annotations: local annotation file (project)
- See documentation: edit-in-source-code-7d8e942.md
```

STEP: Include UI icon stylesheet (project asset reference)

DESCRIPTION: Projects may reference the SAP icons stylesheet from the repository. Preserve this file path when generating or validating project assets.

LANGUAGE: HTML

CODE:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>
```

STEP: Related configuration reference

DESCRIPTION: For the structural outline of page elements and examples of the Application Modeler UI, consult the Configure Page Elements documentation.

LANGUAGE: Text

CODE:
```Text
See: configure-page-elements-047507c.md
```

fiori-tools
annotations
UI.FieldGroup
UI.Facets
OData V4
Page Editor
Application Modeler


**TITLE**: Maintaining OData Annotations with Language Server (CAP CDS & XML)

**INTRODUCTION**: Action-oriented guide to enable and configure language-server support for maintaining OData annotations in CAP CDS (.cds) and XML annotation files. Covers required project files, manifest.json configuration, local metadata and annotation file structure, and supported vocabularies. Use these steps to get code completion, validation, navigation, and i18n support in your editor.

**TAGS**: fiori-tools, cds, odata, annotations, language-server, manifest.json, xml, metadata, i18n, sap

**STEP**: 1 — Enable CDS OData Language Server support

**DESCRIPTION**: Add or enable the SAP CDS OData language-server support used for .cds files. This support is provided by the npm package and included with the SAP CDS Language Support VS Code extension.

**LANGUAGE**: Shell / Metadata

**CODE**:
```shell
# VS Code extension identifier (SAP CDS Language Support)
# Install in VS Code (if using code CLI)
code --install-extension SAPSE.vscode-cds

# npm package (library used by the language server)
# You may reference or pin this package in dev tooling or CI if needed
npm install @sap/ux-cds-odata-language-server-extension --save-dev
```

**STEP**: 2 — Prepare service metadata (local copy)

**DESCRIPTION**: The XML language-server uses a local copy of the OData service metadata for completion and diagnostics. Ensure the metadata file contains edmx:DataServices with one or more edm:Schema elements and exactly one EntityContainer. Namespace must not contain slashes and must match annotation files.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- Example: webapp/localService/metadata.xml -->
<edmx:Edmx Version="4.0" xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx">
  <edmx:DataServices>
    <Schema Namespace="My.Service" xmlns="http://docs.oasis-open.org/odata/ns/edm">
      <EntityType Name="MyEntity">
        <Key><PropertyRef Name="ID"/></Key>
        <Property Name="ID" Type="Edm.String" Nullable="false"/>
        <Property Name="Name" Type="Edm.String"/>
      </EntityType>
      <EntityContainer Name="Container">
        <EntitySet Name="MyEntities" EntityType="My.Service.MyEntity"/>
      </EntityContainer>
    </Schema>
  </edmx:DataServices>
</edmx:Edmx>
```

**STEP**: 3 — Create or validate local annotation XML file(s)

**DESCRIPTION**: Add at least one annotation XML file under /webapp/annotations. The Schema Namespace in the annotation file must match the metadata Namespace. Files must include edmx:DataServices and Schema nodes.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- Example: webapp/annotations/annotation.xml -->
<edmx:Edmx Version="4.0" xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx">
  <edmx:DataServices>
    <Schema Namespace="My.Service" xmlns="http://docs.oasis-open.org/odata/ns/edm">
      <Annotations Target="My.Service.MyEntity">
        <Annotation Term="UI.HeaderInfo">
          <!-- Example annotation content -->
        </Annotation>
      </Annotations>
    </Schema>
  </edmx:DataServices>
</edmx:Edmx>
```

**STEP**: 4 — Configure manifest.json (Uri, localUri, annotations, i18n)

**DESCRIPTION**: Ensure manifest.json contains data source entries with Uri and localUri pointing to the local metadata copy, an annotations list referencing local annotation XML files, and an @i18n model with uri to i18n.properties. All paths are relative to manifest.json.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "sap.app": {
    "id": "my.app"
  },
  "sap.ui5": {
    "models": {
      "i18n": {
        "type": "sap.ui.model.resource.ResourceModel",
        "settings": {
          "bundleName": "i18n.i18n"
        }
      }
    },
    "resources": {},
    "dataSources": {
      "mainService": {
        "uri": "/sap/opu/odata/sap/MY_SERVICE_SRV/",
        "type": "OData",
        "settings": {
          "localUri": "localService/metadata.xml"
        }
      }
    },
    "annotations": [
      {
        "id": "annotations",
        "uri": "annotations/annotation.xml",
        "service": "mainService"
      }
    ]
  }
}
```

**STEP**: 5 — File locations & opening workflow for editor integration

**DESCRIPTION**: Place annotation files in /webapp/annotations and open them in the code editor (single/double-click or from Service Modeler). The XML annotation language server will activate for local annotation files and use the manifest.json localUri to find metadata. Keep local metadata synchronized with backend metadata.

**LANGUAGE**: Paths / Shell

**CODE**:
```text
# Typical project structure
/webapp/
  annotations/
    annotation.xml      <-- open in editor to enable XML annotation LS assistance
  localService/
    metadata.xml        <-- local metadata copy referenced by manifest.json
  i18n/
    i18n.properties     <-- referenced by manifest.json @i18n model
manifest.json
```

**STEP**: 6 — Supported vocabularies (useful for code completion)

**DESCRIPTION**: The XML annotation language server provides completions and validation based on OASIS and SAP OData vocabularies (OData v4.0). Use these standard vocabularies in annotations.

**LANGUAGE**: Text / Links

**CODE**:
```text
# OData (OASIS) vocabularies (examples)
Org.OData.Aggregation.V1
Org.OData.Authorization.V1
Org.OData.Capabilities.V1
Org.OData.Core.V1
Org.OData.JSON.V1
Org.OData.Measures.V1
Org.OData.Repeatability.V1
Org.OData.Temporal.V1
Org.OData.Validation.V1

# SAP vocabularies (examples)
Analytics, CodeList, Common, Communication, DataIntegration,
Direct-Edit, Graph, Hierarchy, HTML5, ODM, PDF, PersonalData, Session, UI
```

**STEP**: 7 — Important constraints and sync notes

**DESCRIPTION**: Follow these limitations and sync guidance to avoid inconsistent diagnostics or missing completions.

**LANGUAGE**: Text

**CODE**:
```text
- Annotations embedded directly inside service metadata are NOT supported by the XML annotation language server.
- Dynamic expressions in annotations are NOT supported.
- Local copies of metadata and back-end annotations are used for completion/diagnostics. They must be kept in sync with the back end; syncing is not automatic.
- Metadata namespace MUST NOT contain '/' characters; namespaces must be dot-separated SimpleIdentifiers.
```

fiori-tools cds odata annotations language-server manifest.json xml metadata i18n sap


**TITLE**: Maintaining Building Blocks in Page Editor (Fiori Tools)

**INTRODUCTION**: Use the Page Editor in Fiori Tools to add and maintain SAP Fiori elements building blocks for OData V4-based applications. This guide lists supported building blocks, explains where to add them (custom page or custom section), and gives action-oriented steps to add, configure, and persist XML and annotation properties using the Page Editor UI.

**TAGS**: fiori-tools, page-editor, building-blocks, sap-fiori-elements, odata-v4, ui5

**STEP**: 1 — Supported building blocks and context

**DESCRIPTION**: The Page Editor supports adding these building block types to custom pages or custom sections in an object page for OData V4 applications. Use this step to confirm which block types you can add and where each is allowed.

**LANGUAGE**: text

**CODE**:
```text
Supported building blocks (Page Editor):
- Chart
- Filter Bar
- Table
- Page (Custom page only)
- Rich Text Editor (Custom section only)

Context:
- Add to: Custom Page OR Custom Section of an Object Page
- Data model: OData V4-based SAP Fiori elements applications
- Property editing: XML properties and Annotation properties (both editable in Property Panel)
```

**STEP**: 2 — Read building block documentation reference

**DESCRIPTION**: Open the official Building Block Overview for implementation details, patterns, and block capabilities. Keep this reference available when generating or validating code/annotations.

**LANGUAGE**: text

**CODE**:
```text
Reference:
Building Block Overview:
https://ui5.sap.com/test-resources/sap/fe/core/fpmExplorer/index.html
```

**STEP**: 3 — Add a custom page or custom section using Page Editor (UI steps)

**DESCRIPTION**: Use the Page Editor UI in Fiori Tools (e.g., VS Code extension) to add a custom page or section, then add a building block to it. These are the step-by-step UI operations to automate or reproduce programmatically if needed.

**LANGUAGE**: text

**CODE**:
```text
UI steps (manual or to automate with UI-driven tests):
1. Open your project in VS Code with Fiori Tools.
2. Open Page Editor for the target Object Page.
3. To add a custom page:
   - Click "Add Custom Page"
   - Provide a title/ID for the page
   - Confirm creation
4. To add a custom section in an object page:
   - Select target Object Page
   - Click "Add Custom Section"
   - Provide a title/ID for the section
5. To add a building block to the new page/section:
   - With the page/section selected, click "Add Building Block"
   - Choose one of: Chart, Filter Bar, Table, Page (page only), Rich Text Editor (section only)
6. Save changes in the Page Editor and in the project.
```

**STEP**: 4 — Edit properties in the Property Panel (XML properties and annotations)

**DESCRIPTION**: The Page Editor exposes a property panel with two categories: XML properties (view/control-level properties) and Annotation properties (OData metadata-driven settings). Use the panel to modify both types; saving persists changes into your project artifacts (annotations/XML fragments).

**LANGUAGE**: text

**CODE**:
```text
Property Panel usage:
- Open the Property Panel for the selected building block.
- XML properties: Edit control/view properties (binding paths, layout, control IDs).
- Annotation properties: Edit annotations that drive behavior (e.g., selection fields, lineItem definitions).
- Workflow:
   1. Change values in the panel
   2. Validate changes via preview or run the app
   3. Save to persist changes to annotation files or XML fragments
```

**STEP**: 5 — Visual references and assets (images used by documentation)

**DESCRIPTION**: Reference images used in the original documentation to aid visual understanding or include them in generated documentation. Keep the file paths unchanged when reusing these assets.

**LANGUAGE**: text

**CODE**:
```text
Documentation images (preserve file paths):
- Custom page example:
  images/Custom_Section_9fbfc17.png

- Custom section with Table building block and Property Panel:
  images/Custom_Section_Building_Block_8af206b.png
```

fiori-tools page-editor building-blocks sap-fiori-elements odata-v4 ui5


**TITLE**: Maintaining Extension-Based Elements (Fiori Tools Page Editor — ext artifact patterns)

**INTRODUCTION**: This guide explains the actions to add and maintain extension-based UI elements (custom columns, fields, sections, views, actions, and controller extensions) using the Page Editor and Page Map in Fiori Tools. It focuses on what is generated (file paths, required metadata) and the minimal code artifacts created under the project's ext/ folder. Distinguishes OData V2 vs V4 behavior and version requirements.

**TAGS**: fiori-tools, sap, odata-v2, odata-v4, extension, fragments, controller, ext, ux-specification, fe-fpm-writer

**STEP**: Note — Templates and writer source

**DESCRIPTION**: For OData V4 applications, the Page Editor templates are published in the open-source writer package. Inspect or reuse templates and generation logic from the package linked below.

**LANGUAGE**: Plain

**CODE**:
```text
@SAP Open UX tools: @sap-ux/fe-fpm-writer
GitHub: https://github.com/SAP/open-ux-tools/tree/main/packages/fe-fpm-writer
```

**STEP**: Adding Custom Column (OData V2 only)

**DESCRIPTION**: In Page Editor outline, click + next to Columns. Provide Column Key, Header Text, ID (auto-generated/editable), choose Column Fragment (create or existing), Column Fragment Name, for responsive tables choose/select Cell Fragment and Cell Fragment Name, select Anchor Column and Placement (before/after). If your column binds to a property (e.g., {Price}), include a leadingProperty entry in the column definition. Generated files (fragment(s)) are written to the project's ext folder. You can reorder or delete the custom column in the outline.

**LANGUAGE**: JSON

**CODE**:
```json
{
  "columns": [
    {
      "key": "CustomColumnKey",
      "label": "Price",
      "id": "ext::CustomColumn_1",
      "fragment": "ext/fragments/CustomColumn.fragment.xml",
      "cellFragment": "ext/fragments/CustomCell.fragment.xml",
      "anchor": "ExistingColumnKey",
      "placement": "after",
      "leadingProperty": "Price"
    }
  ]
}
```

**STEP**: Adding Custom Column (OData V4 only)

**DESCRIPTION**: In Page Editor outline, click + next to Columns. Provide Header Text, select/create Column Fragment and name, choose Anchor Column and Placement (before/after), optionally enable Generate Event Handler (True/False), and set Width. The custom fragment and optional default controller code are written to ext/. Reorder/delete via outline.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// Example generated controller handler (ext/controllers/CustomColumn.controller.js)
sap.ui.define([], function () {
  "use strict";
  return {
    onCustomAction: function (oEvent) {
      // demo handler created when "Generate Event Handler" = true
      // oEvent.getSource() gives the originating control
      // Add implementation here
    }
  };
});
```

**STEP**: Adding Custom Section (Object Page)

**DESCRIPTION**: In Object Page outline, click + on Sections (OData V4: "Add Custom Section" choice). Provide Title, View Type (View or Fragment — V2 only), select/create Fragment/View and name, select Anchor Section and Placement (before/after, V2 also supports replace), and for V4 decide Generate Event Handler to create demo controller. Generated fragment/view and optional controller are written to ext/. You can reorder/delete in outline.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- ext/sections/CustomSection.fragment.xml -->
<core:FragmentDefinition xmlns="sap.m" xmlns:core="sap.ui.core">
  <Panel headerText="Custom Section - Title">
    <!-- Add controls and bindings here -->
  </Panel>
</core:FragmentDefinition>
```

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// ext/controllers/CustomSection.controller.js (optional demo controller)
sap.ui.define([], function () {
  "use strict";
  return {
    onInit: function () {
      // initialization logic for custom section
    }
  };
});
```

**STEP**: Adding Custom Field (Object Page)

**DESCRIPTION**: In Object Page outline, click + on Fields and choose Add Custom Field. Provide Label, choose/create Fragment/View and name, pick Anchor field and Placement (before/after), and optionally Generate Event Handler. The field fragment and optional controller code are written to ext/. Reorder/delete using outline.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- ext/fields/CustomField.fragment.xml -->
<core:FragmentDefinition xmlns="sap.m" xmlns:core="sap.ui.core">
  <HBox>
    <Label text="Custom Field Label" />
    <Input value="{/SomeProperty}" />
  </HBox>
</core:FragmentDefinition>
```

**STEP**: Adding Custom Action (OData V4 only)

**DESCRIPTION**: In Page Editor, click + on Actions and choose Add Custom Action. Provide Action ID, Button Text, Anchor action key and Placement, choose to add to an existing Action Handler file or create new, select/create Handler Method, and toggle Required Selection. The action entry and handler are written to ext/. This feature requires @sap/ux-specification >= 1.96.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// Example action handler file: ext/actions/ActionHandler.js
sap.ui.define([], function () {
  "use strict";
  return {
    onCustomButtonPress: function (oEvent) {
      // Implement action logic here
      // For selection-dependent actions, use oEvent.getParameter("selectedContexts")
    }
  };
});
```

**STEP**: Adding Custom View (OData V4 only)

**DESCRIPTION**: In Page Editor, click + on View and choose Add Custom View (only for List Reports without a chart). Provide Key, Label, select/create Fragment and Fragment Name, and optionally Generate Event Handler. The view fragment and optional controller are written to ext/. Requires @sap/ux-specification versions noted below.

**LANGUAGE**: XML

**CODE**:
```xml
<!-- ext/views/CustomView.fragment.xml -->
<core:FragmentDefinition xmlns="sap.m" xmlns:core="sap.ui.core">
  <Page title="Custom View">
    <!-- Custom layout and controls -->
  </Page>
</core:FragmentDefinition>
```

**STEP**: Adding Controller Extension (OData V4 only, via Page Map)

**DESCRIPTION**: Launch Page Map, click Show Controller Extensions for the selected page, view existing extensions in the Properties Panel, and click Add Controller Extension to create a new extension. Provide required details in the pop-up. You can reorder execution order via drag-and-drop or Move Up / Move Down icons, and open the controller source via Edit in source code. Generated controller extension code is written to ext/ and registered so the runtime will load it for the page.

**LANGUAGE**: JavaScript

**CODE**:
```javascript
// ext/controllerExtensions/CustomControllerExtension.controller.js
sap.ui.define([], function () {
  "use strict";
  return {
    onInit: function () {
      // extension init
    },
    onAfterRendering: function () {
      // post-render logic
    }
  };
});
```

**STEP**: Version and compatibility notes

**DESCRIPTION**: Keep UX-specification & tooling compatibility in mind:
- Custom Actions & Views: only available for OData V4 and require @sap/ux-specification >= 1.96 (specific minimums: 1.96.29, 1.102.14 or higher are noted for some features).
- For OData V4 Page Editor templates, see the fe-fpm-writer package for the exact templates and generated code patterns.

**LANGUAGE**: Plain

**CODE**:
```text
@npm package: https://www.npmjs.com/package/@sap/ux-specification
Required: @sap/ux-specification >= 1.96 (check specific feature release notes)
```

fiori-tools sap odata-v2 odata-v4 extension fragments controller ext ux-specification fe-fpm-writer


**TITLE**: Micro-snippets for XML Annotation LSP (fiori-tools)

**INTRODUCTION**: Micro-snippets are context-specific code-completion templates provided by the XML Annotation Language Server (LSP). Use them to insert common annotation constructs (targets, terms, records, property values) quickly and reliably instead of typing manually. Micro-snippets speed development, reduce typos, and ensure required properties are present.

**TAGS**: fiori-tools, micro-snippets, XML, annotations, code-completion, LSP

**STEP**: 1 — Insert an annotation target micro-snippet

**DESCRIPTION**: When editing inside a <Schema> element, trigger code completion to select the annotation-target micro-snippet. The micro-snippet inserts the full Annotations element and places the cursor inside the Target attribute quotes for immediate typing or selection.

**LANGUAGE**: XML

**CODE**:
```xml
<Annotations Target=""></Annotations>
```

**STEP**: 2 — Choose between record micro-snippet variants

**DESCRIPTION**: For annotation records, two micro-snippet variants are provided:
- Required-only variant: includes only properties defined as nullable=false in the vocabulary (minimal, safe starting point).
- Full-record variant: includes all properties defined for the record (complete template).

Use the required-only variant to start minimal records and add properties later, or use the full-record variant and delete unused properties as needed. Trigger these via code completion when inserting a record instance.

**LANGUAGE**: text

**CODE**:
```
(Use code completion to select "record (required-only)" or "record (full)"—no static code snippet here)
```

**STEP**: 3 — Insert terms and property-value micro-snippets

**DESCRIPTION**: Micro-snippets are also provided for:
- Annotation terms (insert common term templates)
- Property values (insert value templates for properties)
Trigger code completion in the appropriate context (inside Annotations, Records, or Properties) and select the matching micro-snippet to insert the prebuilt block.

**LANGUAGE**: text

**CODE**:
```
(Trigger code completion inside the property or term context and select the desired micro-snippet)
```

**STEP**: 4 — Preview micro-snippet content with Documentation (Quick Info)

**DESCRIPTION**: In the code-completion list, highlight any micro-snippet to see its code template in the Documentation (Quick Info) window. Use this preview before committing the snippet to confirm which variant to insert.

**LANGUAGE**: text

**CODE**:
```
(Highlight snippet in completion list → Documentation (Quick Info) shows the template)
```

**STEP**: 5 — Practical workflow recommendations

**DESCRIPTION**:
- Prefer micro-snippets for common constructs to reduce manual typing and errors.
- Start with required-only record snippets when you only need mandatory properties; add optional properties later.
- Use full-record snippets when you want a complete template to modify.
- Use the Documentation (Quick Info) preview to inspect snippet contents before insertion.

**LANGUAGE**: text

**CODE**:
```
(Workflow: trigger completion → preview snippet in Quick Info → insert → edit fields / attributes)
```

fiori-tools micro-snippets XML annotations code-completion LSP


**TITLE**: Multiple Views for List Report (Fiori tools)

**INTRODUCTION**: Configure a List Report to include additional table or chart views (displayed as icon-tab views). Steps cover adding/removing/moving views in the Page Editor, required annotation and manifest changes, measure creation rules, and presentation-variant considerations.

**TAGS**: fiori-tools, list-report, views, chart, table, manifest.json, annotations, analytics, aggregation, SAPUI5

**STEP**: 1 — Add a Table or Chart View (Page Editor)
**DESCRIPTION**: Use the Page Editor to add a table or chart view. For charts, select an Entity and specify the chart type, dimension and either an existing measure or create a new measure (requires transformation aggregations and SAPUI5 >= 1.106). The table view is added without columns; add columns via the Columns subnode in the Page Editor.
**LANGUAGE**: None
**CODE**:
```text
UI flow:
1. Open Page Editor for the List Report page.
2. Click + (Add) on the Views node.
3. Choose "Add Table View" or "Add Chart View".
   - If Chart: choose chart type, dimension, and measure:
       * Use existing measure  OR
       * Create new measure (transformation aggregation required; SAPUI5 >= 1.106)
4. Click Add. A new view subnode with generated label is appended under Views.
```

**STEP**: 2 — Measure creation rules for Chart View
**DESCRIPTION**: If selecting "Create new measure", Page Editor will apply a transformation aggregation to the selected aggregable property using your chosen aggregation method and generate a dynamic measure. This only works when the service defines aggregable/groupable properties (via @Aggregation.ApplySupported) and when transformation aggregation support is available (SAPUI5 >= 1.106). If all possible dynamic measures are already present, you must choose an existing measure.
**LANGUAGE**: Annotation/OData
**CODE**:
```xml
<!-- Example of a transformation aggregated property that may be generated/applied -->
<Property Name="Revenue" Type="Edm.Decimal">
  <Annotation Term="Analytics.AggregatedProperty">
    <Record>
      <PropertyValue Property="AggregatedBy" String="SUM"/>
      <!-- Other aggregation metadata as generated -->
    </Record>
  </Annotation>
</Property>
```

**STEP**: 3 — Annotations generated when adding a view
**DESCRIPTION**: Adding a table or chart view generates or updates annotations targeting the selected EntityType and creates a qualified UI annotation for the view. If you created a new measure, @Analytics.AggregatedProperty is applied. The Views/Paths entry in manifest.json is generated or appended; if you choose an EntitySet different from the List Report's main EntitySet, that EntitySet is added to the paths entry.
**LANGUAGE**: XML
**CODE**:
```xml
<!-- Example: generated UI annotation with qualifier for a view -->
<Annotations Target="MyService.MyEntityType" xmlns="http://docs.oasis-open.org/odata/ns/edm">
  <Annotation Term="UI.LineItem" Qualifier="MyView">
    <Collection>
      <!-- LineItem/columns definitions for the generated table -->
    </Collection>
  </Annotation>

  <!-- Or for chart views -->
  <Annotation Term="UI.Chart" Qualifier="MyChartView">
    <Record>
      <!-- Chart metadata: Dimensions, Measures, ChartType -->
    </Record>
  </Annotation>
</Annotations>
```

**STEP**: 4 — manifest.json updates (Views/Paths and defaultTemplateAnnotationPath)
**DESCRIPTION**: Page Editor updates manifest.json to register view annotation paths. If a Views/Paths section did not exist, it is created. When all additional views are removed and only the main-table remains, Views/Paths is removed and defaultTemplateAnnotationPath may be created to revert to a plain List Report.
**LANGUAGE**: JSON
**CODE**:
```json
// Example manifest.json "sap.ui.generic.app" fragment after adding multiple views
{
  "sap.ui.generic.app": {
    "routes": [ /* ... */ ],
    "pages": [
      {
        "entitySet": "MainEntitySet",
        "component": { /* ... */ },
        "settings": {
          "views": {
            "paths": [
              "com.example.v1::MainSelectionPresentationVariant",   // main table view
              "com.example.v1::OtherEntitySelectionPresentationVariant" // added table/chart view
            ]
          }
        },
        // If the app reverts to plain List Report, "views/paths" is removed and:
        // "defaultTemplateAnnotationPath": "com.example.v1::MainSelectionPresentationVariant"
      }
    ]
  }
}
```

**STEP**: 5 — Move or reorder views
**DESCRIPTION**: Reorder view sequence under the Views node using drag-and-drop or Move Up / Move Down icons in Page Editor. This changes the tab order shown in the app.
**LANGUAGE**: None
**CODE**:
```text
UI flow:
- In Page Editor: expand Views node, drag a view subnode to a new position OR
  use Move Up / Move Down icons on the view subnode to reorder.
```

**STEP**: 6 — Delete a Table or Chart View
**DESCRIPTION**: Remove a view by clicking the Delete (trash) icon on the view subnode. You cannot remove the last table view that is based on the main EntitySet. When all secondary views are removed the List Report converts back to a plain List Report and Page Editor updates manifest.json/annotation entries accordingly.
**LANGUAGE**: JSON
**CODE**:
```json
// Example manifest.json after deleting all extra views (views/paths removed):
{
  "sap.ui.generic.app": {
    "pages": [
      {
        "entitySet": "MainEntitySet",
        "settings": {
          "defaultTemplateAnnotationPath": "com.example.v1::MainSelectionPresentationVariant"
        }
      }
    ]
  }
}
```

**STEP**: 7 — View properties: View Label and Presentation Variant
**DESCRIPTION**:
- View Label: editable text used as the icon-tab label; auto-generated when adding a view and can be prepared for translation (i18n).
- Presentation Variant: defines table/chart representation rules (sorting, select fields). Presentation Variant for each view must be distinct (cannot reuse the same Presentation Variant across views that might reference different entities). For charts, maintain presentation variant similar to Analytical Chart setup.
**LANGUAGE**: None
**CODE**:
```text
Notes:
- Change the auto-generated View Label in the Page Editor to a meaningful, translatable string.
- Create/maintain Presentation Variant annotations per view (SelectionPresentationVariant/PresentationVariant) to control sorting/selection for that specific view.
```

**STEP**: 8 — Requirements and constraints
**DESCRIPTION**: Key constraints to check before adding chart/table views:
- Service must expose groupable/aggregable properties via @Aggregation.ApplySupported to enable chart view generation.
- Custom aggregation measures require @Aggregation.CustomAggregate on the service if you want custom aggregation methods.
- For transformation aggregation support (created dynamic measures using transformation aggregations), run the app with SAPUI5 1.106 or higher.
- Multiple views are not allowed if an Analytical Chart is configured above or as alternative to the main table; remove the Analytical Chart to enable views.
**LANGUAGE**: None
**CODE**:
```text
Checklist:
- Ensure service has @Aggregation.ApplySupported for chart generation.
- If using custom aggregations, ensure @Aggregation.CustomAggregate exists.
- Use SAPUI5 >= 1.106 for transformation aggregation (@Analytics.AggregatedProperty support).
- Remove any configured Analytical Chart above/alternative to main table before adding multiple views.
```

**STEP**: 9 — Assets and file references
**DESCRIPTION**: Keep stylesheet and image references if your Page Editor examples or UI need SAP icon fonts or images.
**LANGUAGE**: HTML
**CODE**:
```html
<link rel="stylesheet" type="text/css" href="../css/sap-icons.css"/>

<!-- Image used in docs / editor UI -->
<img src="images/Fiori_tools_List_Report_Multi_Views_Nodes_Example_f32ee78.png" alt="Nodes example for List Report" />
```

fiori-tools list-report views chart table manifest.json annotations analytics aggregation SAPUI5


**TITLE**: Navigation to References (XML annotation language server)

**INTRODUCTION**: Use the XML annotation language server to find where annotations and metadata elements (entity types, properties, actions, annotation terms/qualifiers) are referenced in the codebase. This helps assess impact before changing annotations or metadata.

**TAGS**: fiori-tools, annotations, metadata, references, xml, editor, navigation, vscode

**STEP**: Find All References

**DESCRIPTION**: Place the text cursor inside a metadata element name or an annotation term/qualifier to list every reference across the workspace. The results open in the References pane; select an item to navigate to the file for review or update. When run for metadata elements, the element definitions are also included in the results.

**LANGUAGE**: Editor Commands

**CODE**:
```text
Trigger Find All References:

- Keyboard (Windows): Alt + Shift + F12
- Keyboard (macOS): Option + F12
- Mouse: Right-click → Find All References

Behavior:
- Opens the References pane (side/bottom depending on editor layout)
- Shows all references for the selected annotation term/qualifier or metadata element
- Includes definitions when the target is a metadata element
- Click an entry to open and edit the file
```

**STEP**: Go to References

**DESCRIPTION**: Place the text cursor inside a metadata element name or an annotation term/qualifier to open a peeked list of references inline. This allows quick inspection and in-place edits without switching files.

**LANGUAGE**: Editor Commands

**CODE**:
```text
Trigger Go To References:

- Keyboard: Shift + F12
- Mouse: Right-click → Go To References

Behavior:
- Opens a peeked editor view showing the list of references
- Allows direct edits in the peeked view
- Use this for quick, in-context changes without fully opening target files
```

fiori-tools annotations metadata references xml editor navigation vscode