Use specialised renderers for logical model instances#1249
Use specialised renderers for logical model instances#1249johngrimes wants to merge 3 commits intoHL7:masterfrom
Conversation
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.
|
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.
|
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:
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. |
When rendering logical model instances (Binary resources containing logical model data), the publisher now attempts to use specialised renderers from
RendererFactoryinstead of always displaying raw JSON/XML.For example, a
ViewDefinitioninstance will now render usingViewDefinitionRendererif available, producing a more readable narrative than syntax-highlighted JSON.This restores functionality previously worked, but a regression broke it at some point.
Changes:
RendererFactoryfor a specialised renderer matching the logical model typeProfileDrivenRenderer), use it to build the narrativecontentTypeto prevent NPEsFallback 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.