Dynamic Feed — Template Resolution, Content Adapters & DynamicPageOrchestrator

1. Where template resolution sits in the pipeline

All template-resolution types live in ALPAMobile.Presentation/Adapters/ — deliberately split out of ALPAMobile.Presentation/Components/, which holds pure, service-free mappers only. DynamicPageOrchestrator and every IFeedTemplateContentFactory implementation are the app's designated async/IO boundary (RawRepresentationFactory rule): they're the only pieces in this pipeline allowed to resolve a service and await it.

Callers: MecHomePage.razor.cs (route /home-mec, live IHomeFeedQueries → DynamicContentApiClient → gatewayapi.alpa.org), HomeAlpaPage.razor.cs (route /home-alpa, backed by MockAlpaHomeFeedService), and DynamicFeedOrchestratorPage.razor.cs (route /dynamic-feed-orchestrator?page={pageKey}, CMS deep links) — each awaits Feed.GetPageAsync(pageKey) then Orchestrator.ResolveAsync(page) in OnInitializedAsync, wrapped in try/catch falling back to an empty component list. HomePreviewPage.razor.cs (route /home-preview) is the one exception — it still calls PageFactory.Create directly, skipping template resolution, as the legacy shape for pages that haven't rolled up onto templates yet.

Everything left of PageFactory.Create can still touch a raw PageDto with templated items in it. Everything at or right of it only ever sees fully static items — ContainerFactory and ItemComponentFactory are unmodified by this work and never learn templates exist.

2. IFeedTemplateContentFactory — the per-content-type adapter contract

One implementation is registered per ContentType string. An unrecognized ContentType is not an error at the DynamicPageOrchestrator level — it's the same forward-compatibility rule as an unknown ItemType or ContainerType elsewhere in this pipeline: the templated item is dropped, the rest of the page renders normally.

2b. Single-row adapters — PilotCardFactory & LecLinkFactory

Both live in ALPAMobile.Presentation/Adapters/ alongside DynamicListFactory, and both resolve a template to exactly one ItemDto rather than expanding to a collection.

3. DynamicListFactory — contentType: "DynamicList"

The collection-shaped adapter: resolves a server-driven collection of items — a list whose membership isn't known until the device asks for it — as opposed to the single-row adapters above.

Data source: a new port, IItemsQueries.GetItemsAsync(scope, category, filterValue, cancellationToken), returning IReadOnlyList<ItemDto> — already component-shaped rows, not a raw DTO needing further mapping. It lives in ALPAMobile.Application/Abstractions/HomeFeed/IItemsQueries.cs, alongside IHomeFeedQueries (the two are distinct: IHomeFeedQueries fetches an already-composed PageDto; IItemsQueries fetches the flat row set a dynamic list template pulls from).

4. DynamicPageOrchestrator — the orchestrator

DynamicPageOrchestrator.ResolveAsync(PageDto page, CancellationToken) walks page.Containers, and within each container's Items:

1. An item with Template is null is static — kept as-is, in place.
2. An item with Template set is dispatched by Template.ContentType to the matching IFeedTemplateContentFactory (resolved from an IEnumerable<IFeedTemplateContentFactory> injected into the constructor and keyed into a dictionary once). The single templated item is replaced in place by however many ItemDtos the adapter's ResolveAsync returns — zero, one, or many.
3. A missing ContentType or one with no registered adapter drops the item — never the container, never the page.

Once every container's item list is fully static, DynamicPageOrchestrator hands the same PageDto to the existing, unmodified PageFactory.Create and returns the resulting PageViewModel directly — callers get one method to await instead of having to remember to chain resolution and mapping themselves.

5. Source map & status