When true (default), the grid self-loads the entity's active EntityActions and shows them — buttons
appear only for entities that actually have actions (data-driven). Actions whose invocation names a
RuntimeUXDriverClass mount that interactive driver (e.g. the Record Process runner) in-place.
Opaque per-view configuration. Seeds the grid bindings; mutated + re-emitted on grid changes.
Emitted when this renderer mutates its opaque config (sort / grid-state persistence).
Ask the host to open this view's configuration UI. Raised when the grid emits
ManageColumnsRequested (its "Manage Columns" toolbar affordance). Part of the generic
IViewRenderer contract; the container forwards it to the workspace, which opens the
config panel (Columns tab) — the canonical column editor.
NAVIGATION: create a new record of the current entity (grid "New" button). Bubbles up for routing.
Generic data-access channel: ask the host to re-load with different sort / page.
ProtecteddeleteDynamic message for the delete-confirmation dialog (reflects the staged record count).
The entity whose records are being rendered. Used to build default params + resolve selection.
Active filter text — passed through for the grid's cell highlighting.
Protected OptionalgridReference to the hosted grid. Currently only retained for parity / future selection resolution; selection is mapped from the records input rather than read from the grid, per contract.
OptionalisWhether the host is currently (re)loading the record set. Accepted per contract; unused here.
ProtectedlistConfig fed into <mj-list-management-dialog>. Built from the entity + selected records.
NAVIGATION: open a related record on a (possibly different) entity from a foreign-key cell click. Routing lives in the outer app, so this is one of the few signals that legitimately bubbles up.
OptionalpageOne-based current page the host is showing. Fed into [PagerPageNumber] (already 1-based).
OptionalpagePage size the host is using — fallback when config.pageSize is absent.
If specified, this provider will be used for communication and for all metadata purposes. By default, if not provided, the Metadata and RunView classes are used for this and the default GraphQLDataProvider is used which is connected to the same back-end MJAPI instance as the Metadata and RunView classes. If you want to have this component connect to a different MJAPI back-end, create an instance of a ProviderBase sub-class like GraphQLDataProvider/etc, and configure it as appropriate to connect to the MJAPI back-end you want to use, and then pass it in here.
Emitted when a row is double-clicked — payload is the raw record object (host builds the key).
The records to render (already loaded / filtered / paged by the host). Fed into [Data].
Emitted when a row is single-clicked — payload is the raw record object (host builds the key).
Primary-key string of the currently selected record, if any.
ProtectedshowWhether the delete-confirmation dialog is visible. Toggled internally by onDeleteButtonClick.
ProtectedshowWhether the add-to-list dialog is visible. Toggled internally by onAddToListRequested.
OptionaltotalTotal record count across all pages, for the grid's pager. Fed into [TotalRowCount].
StaticɵdirStaticɵfacEffective page size — config wins, else the generic pageSize input, else the grid's own default.
Effective RunViewParams for the grid. Uses config.params when supplied; otherwise builds a
minimal dynamic-view params object from entity. Returns null when no entity is known
yet (the grid renders empty until the host provides one).
Effective selection mode — defaults to 'checkbox' when not set in config.
Effective add-to-list button visibility — defaults to true when not set in config.
Effective pager visibility — defaults to true when not set in config.
Effective toolbar visibility — defaults to true when not set in config.
Returns either the default Metadata provider or the one specified in the Provider property, if it was specified
Returns either the default RunQuery provider or the one specified in the Provider property, if it was specified
Returns either the default RunReport provider or the one specified in the Provider property, if it was specified
Returns either the default RunView provider or the one specified in the Provider property, if it was specified
IMPERATIVE export entry point (IViewRenderer.exportRecords). Lets the host trigger an export programmatically (ultimately for the AI agent) by delegating to the hosted grid's self-contained EntityDataGridComponent.Export (which downloads the file). The grid's toolbar export button remains the interactive path; this is the no-UI equivalent.
Optionalformat: "csv" | "excel" | "json"optional output format; the grid defaults to 'excel' when omitted.
true when the export succeeded, false when the grid isn't ready or the export failed.
Add-to-list button → build a ListManagementDialogConfig from the entity + the records the
grid supplied, then open the Generic list-management dialog. The dialog persists membership
changes itself — nothing bubbles up. Mirrors the config construction the legacy host did in
data-explorer-dashboard's onAddToListRequested().
Row single-click → recordSelected. Extracts the raw record (event.row) so the host
builds the composite key itself, matching the other renderers.
Row double-click → recordOpened (NAVIGATION), emitting the raw record object.
Sort change → both generic coordination channels:
sort shape so the host re-loads with a new OrderBy.config.gridState.sortSettings and emits configChanged so
the grid's sort survives view reloads via the opaque config channel.Delete button → stage the records and open the Generic confirm dialog. The actual delete happens in onDeleteConfirmed after the user confirms — nothing bubbles up.
Delete cancelled → discard the staged records and close the confirm dialog.
Delete confirmed → delete each staged record through the MJ entity layer
(ProviderToUse.GetEntityObject(name, compositeKey, user) → Delete), checking the boolean
result and surfacing failures via LogError. After deletion, re-request the current page
so the host reloads. Self-contained — no feature event leaves the wrapper.
Foreign-key link click → openRelatedRecordRequested (NAVIGATION). Maps the grid's ForeignKeyClickEvent (which carries the related entity + the FK value) onto the generic ViewRelatedRecordNavigation the container forwards to the outer app for routing. The related entity name is taken from the event when present, else resolved from the metadata by ID.
Generic grid-state change (column resize / reorder / visibility) → merge the grid's updated
ViewGridState into the opaque config and emit configChanged; the host persists
the blob verbatim. No dataRequest here — column changes don't alter the loaded record set.
List-management dialog cancelled → tear down state.
List-management dialog completed (membership changes applied) → tear down state.
New button → createRecordRequested (NAVIGATION) — opening the create form is routing.
Pager navigation → generic dataRequest. Maps the grid's PageChangeEvent
(PageNumber is already 1-based, PageSize) onto the generic { page, pageSize } shape the
host honors against its own RunView.
Refresh button → re-emit dataRequest so the host reloads the current page. This is generic container ↔ plug-in coordination (a data-access request), NOT a feature event surfaced to the outer app.
Selection change → kept INTERNAL. The grid drives its own add-to-list from the selection, so the wrapper has no need to surface it. We intentionally do not bubble selection anywhere.
GridViewRendererComponent
The Grid view type renderer — a fully self-contained IViewRenderer adapter that hosts the existing EntityDataGridComponent (
<mj-entity-data-grid>) inside the entity-viewer's pluggable view-type system. It is the dynamic-mounted plug-in that theGridViewTypedescriptor points at.Architectural intent — the container knows nothing about grids, and grid features never bubble up. The host (entity-viewer) binds only the generic IViewRenderer surface: the core inputs (
entity/provider/records/selectedRecordId/filterText/config), the generic data-context inputs (totalRecordCount/page/pageSize/isLoading), and a small set of generic outputs. There is no opaquehostActionchannel — everything a grid does is resolved through one of these three categories:Self-contained (owned end-to-end — never bubbles up):
<mj-entity-data-grid>itself (itsonExportClickopens its OWN export dialog with format/sampling viaExportService). This wrapper does NOT host an export dialog — doing so produced two stacked dialogs.<mj-list-management-dialog>(ListManagementModule). On(AddToListRequested)the wrapper builds a ListManagementDialogConfig from the entity + selected records and opens the dialog.<mj-ev-confirm-dialog>(from EntityViewerModule). On(DeleteButtonClick)the wrapper confirms, deletes via the MJ entity layer, then re-requests data so the host reloads the current page.(RefreshButtonClick)the wrapper re-emits dataRequest so the host reloads. No feature event leaves the wrapper.Navigation (the ONLY legitimate upward signals — routing lives in the outer app):
(ForeignKeyClick)→ openRelatedRecordRequested.(NewButtonClick)→ createRecordRequested.Container ↔ plug-in generic coordination (NOT outer-app signals):
(AfterSort)→ dataRequest (sort) + persisted intoconfig.gridStatevia configChanged.(PageChange)→ dataRequest (page/pageSize).(GridStateChanged)→ merged intoconfig.gridState+ configChanged.Seeding the grid from
configwith defaults: absent config fields fall back to sensible defaults so a brand-new view (config === {}) renders a fully-functional grid — toolbar on, checkbox selection, add-to-list on, pager on. The grid never loads its own data ([AllowLoad]="false") — the host owns the fetch.This is an NgModule-declared (
standalone: false) component, declared inEntityViewerModule. It renders<mj-entity-data-grid>+ the Generic<mj-list-management-dialog>/<mj-ev-confirm-dialog>straight from the module's compilation scope (the module importsListManagementModuleand declares the grid + confirm dialog; the grid component brings its own export dialog) — so there's noimportsarray and, crucially, no self-import ofEntityViewerModule: the module loads the view-type descriptors, which reference these wrappers, so a wrapper importing the module back would form a runtime import cycle (NG0919).Inputs use the camelCase names mandated by the IViewRenderer contract (the host binds them by those exact names via
setInput), rather than MJ's usual PascalCase for public members — mirroring the Cards and Cluster renderers.