FHIR Chat · Changing the way we define menus · IG creation

Stream: IG creation

Topic: Changing the way we define menus

Jose Costa Teixeira (Feb 20 2020 at 21:59):

After some discussions and struggling with the way we define IG menus, here's a first idea for a possible change:

Jose Costa Teixeira (Feb 20 2020 at 22:00):

Instead of defining the menu in an external XML (or an external yaml :wink: ) could we add something to the IG itself?

Jose Costa Teixeira (Feb 20 2020 at 22:01):

Something similar to what we do with the pages:

Jose Costa Teixeira (Feb 20 2020 at 22:03):

having a recursive element (/extension) in the IG, which would add to the standard menu items.

Jose Costa Teixeira (Feb 20 2020 at 22:10):

Something like

{
  "ImplementationGuide": {
...
    "definition": ...,
...
    "menuItems": {
      "menuItem": {
        "label": "My New menu item",
        "url": "somepage.html",
        "menuItems": [
          {
            "label": "My Sub Menu",
            "url": "subpage1.html"
          },
          {
            "label": "Sub Menu 2",
            "url": "subpage2.html"
          }
        ]
      }
    }
  }
}

Jose Costa Teixeira (Feb 20 2020 at 22:11):

where menuItems could be a standard extension as well

Jose Costa Teixeira (Feb 20 2020 at 22:13):

This example would add one menu item to the top bar

Jose Costa Teixeira (Feb 20 2020 at 22:13):

and two submenus under that one

Jose Costa Teixeira (Feb 20 2020 at 22:14):

the template still determines the other menu items

Jose Costa Teixeira (Feb 20 2020 at 22:14):

This only allows to add menu items to the template

Jose Costa Teixeira (Feb 20 2020 at 22:15):

for those who are changing their menus in the menu.xml, how does this sound?

Sarah Gaunt (Feb 20 2020 at 22:29):

Looks good to me. Would we be able to have nested sub-menus like:
pasted image

Lloyd McKenzie (Feb 20 2020 at 23:23):

Right now, the javascript libraries we use don't allow more than two levels, but we wouldn't want the publisher to restrict to that. If we're going to include this in core for the IG (mixed feelings on whether that's appropriate), it'd be nice to be able to point to a page by it's id attribute and thus grab the label and URL from there - so there's only one place in the IG where that's maintained. We'd still need label + URL for external links. Also, the url should be optional if you have child menu items (our current javascript doesn't allow a parent item to have its own link)

Grahame Grieve (Feb 20 2020 at 23:50):

I'd rather not extend the IG for this. I think we could do it as a parameters resource

Lloyd McKenzie (Feb 21 2020 at 02:53):

Referenced by an extension?

Lloyd McKenzie (Feb 21 2020 at 02:53):

Frankly I'd prefer custom XML over that from an authoring perspective

Grahame Grieve (Feb 21 2020 at 03:31):

referenced from a parameter

Lloyd McKenzie (Feb 21 2020 at 03:39):

<Parameters>
<parameter>
<name value="label"/>
<valueString value="some menu item"/>
</parameter>
<parameter>
<name value="uri"/>
<valueUri value="somepage.html"/>
</parameter>
<parameter>
<name value="nestedItem"/>
<part>
<name value="label"/>
<valueString value="some sub-menu item"/>
</part>
<part>
<name value="uri"/>
<valueUri value="somesubpage.html"/>
</part>
</parameter>
</Parameters>

Lloyd McKenzie (Feb 21 2020 at 03:39):

or

Lloyd McKenzie (Feb 21 2020 at 03:40):

<Menu>
<item label="some menu item" uri="somepage.html">
<item label="some sub-menu item" uri=="somesubpage.html"/>
</item>
</Menu>

Lloyd McKenzie (Feb 21 2020 at 03:40):

From an authoring perspective, I think custom XML wins

Lloyd McKenzie (Feb 21 2020 at 03:41):

(or json - though I do like schema validation checking :>)

Chris Moesel (Feb 21 2020 at 03:50):

I'm not necessarily arguing for parameters, but if we allowed code to be dynamic, you could do something like:

"parameters": [{
  "code": "menu:Home",
  "value": "index.html"
},{
  "code": "menu:Menu Item",
  "value": ""
},{
  "code": "menu:Menu Item.Nested Item",
  "value": "nested.html"
},{
  "code": "menu:Menu Item.Nested Item 2",
  "value": "nested2.html"
},{
  "code": "menu:History",
  "value": "history.html"
}]

I'm not sure I love it. Just throwing it out there.

Lloyd McKenzie (Feb 21 2020 at 04:00):

I vaguely recall that we agreed to a change request that Parameters.name needs to be "code-friendly" - i.e. no whitespace, etc.

Chris Moesel (Feb 21 2020 at 14:30):

Ah. OK. Well then I guess that would make that approach infeasible. It makes sense though, as I was surprised to see that a field called code had type string!

Last updated: Apr 12 2022 at 19:14 UTC