Tutorial: build the Task Management views

Documentation status: tutorial — see Maturity and evidence.

Goal

Add a view to Task while clearly separating:

1. page data cache;
2. page state and actions;
3. visual components and bindings.

A view is a projection of the business model. It should not become the source of business meaning.

Conceptual structure

Task view
├── data cache
│   └── datasets / datasources
├── page model
│   ├── local state
│   ├── events
│   └── actions
└── visual projection
    ├── fields
    ├── list
    └── buttons

1. Declare the data cache

XML example:

<lgc:dataSets>
  <lgc:dataCursor name="TaskPageCursor">
    <lgc:dataSet
        name="TaskEntityDs"
        collectionPath="/ClassItem[@name='TaskManagement.Task']/Collection[@name='Entity']">
      <lgc:fields>
        <field name="Id" fieldType="String" />
        <field name="Name" fieldType="String" />
        <field name="Description" fieldType="String" />
        <field name="Priority" fieldType="Integer" />
        <field name="StartDate" fieldType="DateTime" />
        <field name="EndDate" fieldType="DateTime" />
      </lgc:fields>
    </lgc:dataSet>
  </lgc:dataCursor>
</lgc:dataSets>

The exact collection path depends on the loaded package. Always verify the full public name exposed by your model.

2. Initialize page state

The pageModel contains only interaction state local to the page: current filter, selected item, edit mode, and similar values.

Example functionalP logic:

OnlyMine := false;
SelectedTaskId := "";

Do not move business rules into page code when they belong in the model or a published action.

3. Filter before opening the dataset

Apply filters before opening data whenever possible.

if OnlyMine then
  TaskEntityDs.Filter := "AssigneeId = :CurrentUserId";

The exact filter syntax depends on the datasource and Runtime. The example illustrates where the logic belongs.

4. Bind components

A visual component binds to a datasource and a public field:

<lgc:edit
    name="NameEdit"
    nameField="Name"
    dataSource="TaskEntityDs"
    caption="#TaskName" />

<lgc:edit
    name="PriorityEdit"
    nameField="Priority"
    dataSource="TaskEntityDs"
    caption="#Priority" />

Keep binding declarative. Changing the concrete visual implementation should not require duplicating business knowledge.

5. Add Save and Cancel

Save:
  post current object
  refresh current dataset

Cancel:
  cancel current edit
  restore page state

In executable scripts, use operations actually published by the Runtime and component version in use. Documentation must not invent public symbols: executable examples should be certified against the release API or manifest.

6. Create a new task

The “New Task” action should:

1. create a Task instance;
2. initialize required values;
3. switch the page into edit mode;
4. leave business validation to the model;
5. post only after user confirmation.

7. Visual events

Visual events trigger page actions or published business actions. They should not contain a second implementation of the business rule.

Appropriate responsibilities include:

• OnChange: update local filter state;
• OnDoubleClick: open the selected object;
• OnKeyUp: refresh a search;
• Save button: invoke the relevant persistence/validation action.

8. Validate

Before considering the view complete, verify:

• datasource resolution;
• field names match the model;
• pageModel initialization;
• filters are applied before open where possible;
• Save/Cancel behavior;
• object creation;
• no business rule is duplicated in a visual component.

Next step

After model and view validation, publish service capabilities or an API. See Publish a user-management API for the publication pattern.