Views, controllers, and UI publication

Documentation status: reference — see Maturity and evidence.

The logiCells UI layer publishes interactive projections of the executable model. A view is neither the business concept itself nor a graphical class: it describes how a concept, relation, collection, process, or service is presented in an interaction context.

Principle

Read a view in this order:

conceptual projection — which model object or set is exposed;
usage intention — explore, select, consult, edit, validate, navigate;
functional components — fields, lists, tabular views, buttons, regions, panels;
concrete renderer — Web, desktop, mobile, or another target.

The renderer comes last. Business models and view metadata must not depend on a specific UI toolkit.

Page controller

The page controller coordinates local view state, datasets/cursors, functional components, and visual events. It acts as a local interaction bus, but it does not replace model actions, rules, processes, or services.

An interaction that changes business state should be escalated to an explicit business capability. A purely visual interaction may remain local to the page.

Separation of responsibilities

Layer	Responsibility
Conceptual model	business meaning, relations, rules, actions, processes
View	projection, context, interaction intention
UXfc / functional component	expected interaction function
Page controller	local coordination, events, page state
Renderer	appearance, widgets, layout, target-specific behavior

Portability

The same concept may be projected as a list, form, dashboard, Web page, desktop client, mobile experience, or service surface. Portability depends on preserving this separation.

Avoid

placing business rules inside visual components;
coding data access directly into widgets;
making a view definition depend on a native UI class;
treating a local visual event as a public business contract;
treating one view as the only possible representation of a concept.