Hi, we have studied a lot of articles about editable data pages and custom top-level pages but it is not still clear if it corresponds to the best practices to use an editable data page as a temporary UI context.

We understand that the following scenario is totally ok: 1. load data records into editable data page, 2. use the page to show and edit the record on section, 3. call Obj-Save method or use other tools for savable DP.

But what if I need to display other UI elements based on not persistent data that I don't need to save to database after use. For example, complex temporary data structure from different sources (to display on UI) or temporary specific filter/control with pre-defined values: should I store that structure/values in a temporary top-level page (create and pre-load it on certain action using data transform) or should I create special editable data page rule with data transform loader and refer to it as a section context?

First option:

1. Run data transform (may be parameterized) before the section is displayed. Create custom top-level page and fill UI-specific properties.

2. Refer to the top-level page on the section and other rules (for example, controls visibility whens).

Pros:

- No need to create a rule (data page).

- Temporary object for temporary context that can be changed easily.

- If we need to initialize page differently based on parameters it is easier to refer to top-level page in different places (no need to specify parameters value in the name of the object): e.g., TempDashboardUiContext.pyLabel

Cons:

- There is no easy way to share object state across threads (it is not possible to create requestor-level custom top-page)

- It is not obvious where the custom top-level page was created and with what values it was initialized.

- The reference to the custom top-level page in different rules (e.g., whens used on the section) is not obvious also.

Second option:

1. Create editable data page rule specially for the current UI context (may be parameterized). Use data transform as a loader.

2. Refer to the editable data page on the section and other rules (for example, controls visibility whens).

Pros:

- It becomes possible to share object state across threads (create requestor-level pages). For example, we may need to save UI filter values until the requestor session is finished.

- We have a specific rule with description and usage notes, so it is more obvious to refer to it in different UI-related rules (e.g., whens).

Cons:

- We need to create a data page rule and its loader for specific UI. And I may be wrong but the described usage of the rule type is not related to the definition of data page. It doesn't load real data, can it be listed to the data page list?

- There may be situations when the context initialization must be based on parameters value. We must specify parameters value in the name of the object each time we refer it: e.g., D_DashboardUiContext[orgUnit:OperatorID.pyOrgUnit].pyLabel

We heard that top-level pages were previously recommended for the scenario above, but now (with release of 8.3-8.5) the use of custom top-level pages is not preferred anywhere (editable data pages recommended).

What do you think? Is there any best practice?

P.S. Sorry for my English 🤷‍♂️