Skip to content

Use specialised renderers for logical model instances#1249

Open
johngrimes wants to merge 3 commits intoHL7:masterfrom
aehrc:render-logical-model-instances
Open

Use specialised renderers for logical model instances#1249
johngrimes wants to merge 3 commits intoHL7:masterfrom
aehrc:render-logical-model-instances

Conversation

@johngrimes
Copy link
Copy Markdown

@johngrimes johngrimes commented Feb 4, 2026

When rendering logical model instances (Binary resources containing logical model data), the publisher now attempts to use specialised renderers from RendererFactory instead of always displaying raw JSON/XML.

For example, a ViewDefinition instance will now render using ViewDefinitionRenderer if available, producing a more readable narrative than syntax-highlighted JSON.

This restores functionality previously worked, but a regression broke it at some point.

Changes:

  • Query RendererFactory for a specialised renderer matching the logical model type
  • If one exists (i.e., not the generic ProfileDrivenRenderer), use it to build the narrative
  • Fall back to JSON/XML rendering if no specialised renderer exists or if rendering fails
  • Add null safety checks for contentType to prevent NPEs

Fallback behaviour: If the specialised renderer throws an exception or returns null, the code gracefully falls back to the existing JSON/XML rendering, ensuring no regression for edge cases.

When rendering Binary resources that contain logical model instances
(e.g., ViewDefinition), check if a specialised renderer exists before
falling back to JSON/XML rendering.

This enables logical model instances to be rendered with their dedicated
renderers (such as ViewDefinitionRenderer) instead of displaying raw
JSON or XML content.

The fhirTypeRoot() helper extracts the type name from URL-based
resourceTypes used by logical models (e.g., extracting "ViewDefinition"
from "https://example.org/StructureDefinition/ViewDefinition").
Wrap the specialised renderer invocation in try-catch so failures fall
back to JSON/XML rendering instead of crashing. Also add null checks
for renderedXhtml and rXContentType to prevent NPEs.
@lmckenzi
Copy link
Copy Markdown
Contributor

How is logical model versioning handled, as logical model instances don't necessarily indicate what version of a logical model they're constructed against?

Replace the duplicate private static fhirTypeRoot helper with
the existing method on the Element class.
@johngrimes
Copy link
Copy Markdown
Author

Thanks @lmckenzi for taking a look at this, and apologies for the delay in getting back to you.

This change is confined to fixing the invocation of three specialised renderers for logical models. These specialised renderers were pre-existing, and were broken at some point:

  • ViewDefinition
  • WebTemplate
  • FeatureDefinition

My understanding is that the rendering of logical models in IGs does not depend on versioning.

It is run from a switch statement off the type name in RendererFactory in FHIR core.

The version doesn't seem to come into it at all.

For some reason something was changed here in the IG builder repo that broke this - this is an attempt to restore the functionality.

When taking another look at this, I noticed an area of the change that could be simplified further - so I committed this in a5790b3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

2 participants