Stream: IG creation
Topic: Jekyll Processing Narrative
Grahame Grieve (Dec 13 2019 at 00:49):
@Brian Postlethwaite I change the IG publisher to not process Liquid tags in narrative, at your request. Now @Lloyd McKenzie has discovered that he's depending on the processing of such tags
Grahame Grieve (Dec 13 2019 at 00:49):
can you remind me here why you didn't want tags processed in narratives?
Brian Postlethwaite (Dec 13 2019 at 00:50):
My examples text and he'll want that in the SDC guide too.
Brian Postlethwaite (Dec 13 2019 at 00:50):
I linked in an example that has them in it.
Grahame Grieve (Dec 13 2019 at 00:51):
?
Brian Postlethwaite (Dec 13 2019 at 00:51):
The prepopulate search expressions uses handlebars to mark the parameters to replace.
Lloyd McKenzie (Dec 13 2019 at 00:52):
Ah, right
Brian Postlethwaite (Dec 13 2019 at 00:52):
And this was documenting that usage, and also in the examples showing this, and including those snippits.
Brian Postlethwaite (Dec 13 2019 at 00:53):
(deleted)
Lloyd McKenzie (Dec 13 2019 at 00:53):
I'll just put Jekyll tags that turn processing on, then off around the stuff I need processed then.
Grahame Grieve (Dec 13 2019 at 00:54):
so there's several ways to handle this:
- make it a global setting one way or the other, and you use raw/ if you want to differ from the global setting
- make it an ig based setting in the ig.json / ig resource
- use an extension on the narrrative to control it
All of them are possible
Lloyd McKenzie (Dec 13 2019 at 01:01):
In theory, you might want a mix in a single narrative. I'm fine with turning raw off then on around the stuff that needs processing. Default being "no Jekyll" is going to be safest for most.
Eric Haas (Dec 13 2019 at 02:46):
I think an ig based setting is best. Does this mean we could use Jekyll in the source resource instances anywhere. Like substitution of base_urls with {{parameters}} ?
Grahame Grieve (Dec 13 2019 at 02:52):
well, not really. One of the reasons the default is not to process them is because Jekyll only processes them in html instances, not in the resources themselves
Grahame Grieve (Dec 17 2019 at 23:40):
back to this... what I could do is process some specific liquid tags that are clearly intended to be replaced whatever, in the resource itself
Grahame Grieve (Dec 17 2019 at 23:41):
see, for example, this:
Grahame Grieve (Dec 17 2019 at 23:41):
http://build.fhir.org/ig/HL7/davinci-atr/branches/master/qa.html
Grahame Grieve (Dec 17 2019 at 23:42):
The link '{{site.data.fhir.path}}coverage.html' for "Coverage" cannot be resolved
That's a liquid tag in the resource narrative. (@Nagesh Bashyam )
Eric Haas (Dec 18 2019 at 01:20):
I would like that but I may be unique. If there isn't broad support I can easily get by using the full urls.
Lloyd McKenzie (Dec 18 2019 at 04:44):
I just embedded {% %} and {% raw %} tags around the content I wanted liquid to mess with.
Lloyd McKenzie (Dec 18 2019 at 04:44):
Not sure why we need anything more than that.
Grahame Grieve (Dec 18 2019 at 04:45):
because that means your tags go into the published resource.
Grahame Grieve (Dec 18 2019 at 04:45):
a better way is to pre-process the resource so the liquid tags aren't part of the resource itself. A
Grahame Grieve (Dec 18 2019 at 04:46):
at this time I am only processing the link to the FHIR spec, other tags are left untouched .
Grahame Grieve (Dec 18 2019 at 04:47):
and only in metadata resources, not other kinds (e.g. examples)
Lloyd McKenzie (Dec 18 2019 at 04:49):
Ah, so they'd get stripped out of the 'text' element when you publish the actual resource JSON and XML, but would still be used when rendering the HTML of the narrative?
Grahame Grieve (Dec 18 2019 at 04:53):
in the past: you could use to make sure that jekyll would process the narrative when in HTML, but this would leave the narrative in the actual resources (for download + in the package) still containing the liquid tags that you wanted processing, along with the liquid tags as well
now: {{site.data.fhir.path}} will be processed immediately in the resources themselves when the IG pubisher loads them, and all views of the resources will say the same thing. Any other liquid tags are left untouched by the publishing infrastructure unless you use but it would be much better if you don't do that anymore and we specifically process the tags on load
Lloyd McKenzie (Dec 18 2019 at 05:06):
What about paths to dependent IGs?
Lloyd McKenzie (Dec 18 2019 at 05:07):
It'd be nice of {{site.data.*}} got processed automatically...
Grahame Grieve (Dec 18 2019 at 05:11):
I can't process all the things in site.data because many of them don't exist earlier in the run
Last updated: Apr 12 2022 at 19:14 UTC