FHIR Chat · Generating code for Profiles · hapi

Stream: hapi

Topic: Generating code for Profiles

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:20):

So this is a kind of FAQ and I'd like to see if I can progress this. A lot of people would like to see generated code for profiles.

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:20):

A first time knee jerk reaction is to think that you would generate a class model like we do for the base resources.

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:21):

but that's not the case. A resource may conform to multiple profiles, and it may or may not indicate that it does, and you may know that it does even though it doesn't claim to. And you may have code for various profiles, and the base resource - it's all the same information whatever

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:29):

so I've always thought a profile is a view onto a resource - that is, a set of generated classes that are a facade to the base resource. So something like

public class ProfileName {
  public static ProfileName wrap([RT] object, IWorkerContext context);
  public [RT] wrapped();

  public Coding getRace();
  public ProfileName setRace(Coding code);

}

[RT] is the base resource type.

where the generated code would:

  • have generated accessors that access the wrapped class for all existing properties
  • the generated accessors have reduced cardinality if the profile does (e.g. 1..* --> 1..1)
  • the type would be reduced as per the
  • the access is also generated based on ElementDefinition.alias?
  • There would be accessors for named slices

Note that the generated classes will need access to the context because there's quite a lot of magic behind the scenes to do with discriminators

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:31):

I have several questions

  • should the generated code handle non-conformance in the base resource by blowing up? or by ignoring the content that is not conformant?
  • what would the package name be? is that somehow auto-generated or purely config?
  • how performant does it need to be? I think that the answer is: as fast as possible while being truly conformant.
  • But there's some corner cases where a terminology service is needed. That's the opposite of performant... not sure what to do there

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:32):

  • should the name be versioned? Or the package? Or is that delegated to configuration for the generator?

view this post on Zulip Grahame Grieve (Jun 17 2020 at 00:33):

  • is it better to generate one single large class with inner nested classes for each profile, or should it be a package for each profile?

view this post on Zulip Brian Postlethwaite (Jun 18 2020 at 04:38):

This is more or less what I blogged about (for the dotnet usage in the same way - though we'd use extension methods)
https://brianpos.com/2018/05/03/code-generation-fhir-custom-resources/
As for what level to generate, I think that is probably something you'd have in configuration to the generator.
Sometimes you might want to generate the entire package's profiles, other times just the one.
Versioning, hadn't thought about at all - the dotnet libs use the same namespace for all versions, and have a trick to be able to use multiple at the same time.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -