Stream: shorthand
Topic: work around for page-ordering in sushi
Eric Haas (Mar 30 2021 at 16:31):
@Chris Moesel can Sushi use a front matter-like structure on a page to order the pages? so instead of Jekyll front matter since the publisher chokes if you actually use front matter, maybe we could use escaped front matter, something like this at the top of the page:
<!--
---
title: Foo
page-order: '1' #for nesting use dot notation like '1.1'
description: >-
this is my awesome page
---
-->
I did a quick checked to see if it works with the ig publisher and the publisher seems to ignore it for markdown pages.
Eric Haas (Mar 30 2021 at 16:37):
so instead of Sushi generating this alpha based order...
page:
generation: html
nameUrl: toc.html
page:
- generation: markdown
nameUrl: index.html
title: Home
- generation: markdown
nameUrl: basic-auth-example.html
title: Basic Auth Example
- generation: markdown
nameUrl: best-practices.html
title: Best Practices
- generation: markdown
nameUrl: conformance.html
title: Conformance
- generation: markdown
nameUrl: example-request-access-token.html
title: Example Request Access Token
- generation: markdown
nameUrl: example-request-patient.html
title: Example Request Patient
- generation: markdown
nameUrl: example-request-refresh.html
title: Example Request Refresh
- generation: markdown
nameUrl: example-request-token-post.html
title: Example Request Token Post
- generation: markdown
nameUrl: scopes-and-launch-context.html
title: Scopes and Launch Context
- generation: markdown
nameUrl: token-introspection.html
title: Token Introspection
- generation: markdown
nameUrl: worked_example_id_token.html
title: Worked Example Id Token
title: Table of Contents
we could get a customizable page order for TOC generation? (Maybe you already have something I don't know about.)
Eric Haas (Mar 30 2021 at 16:56):
like so...
page:
generation: html
nameUrl: toc.html
title: Table of Contents
page:
- generation: markdown
nameUrl: index.html
title: Launch and Authorization
page:
- generation: markdown
nameUrl: example-request-patient.html
title: Example Request Patient
- generation: markdown
nameUrl: example-request-refresh.html
title: Example Request Refresh
- generation: markdown
nameUrl: example-request-access-token.html
title: Example Request Access Token
- generation: markdown
nameUrl: example-request-token-post.html
title: Example Request Token Post
- generation: markdown
nameUrl: basic-auth-example.html
title: Basic Auth Example
- generation: markdown
nameUrl: scopes-and-launch-context.html
title: Scopes and Launch Context
page:
- generation: markdown
nameUrl: worked_example_id_token.html
title: Worked Example Id Token
- generation: markdown
nameUrl: token-introspection.html
title: Token Introspection
- generation: markdown
nameUrl: conformance.html
title: Conformance
- generation: markdown
nameUrl: best-practices.html
title: Best Practices
Lloyd McKenzie (Mar 30 2021 at 17:01):
In general, we don't want front matter in our source pages... The page order is set by the implementation guide. So is the title.
Chris Moesel (Mar 30 2021 at 17:22):
I think this is something we could do, but it sounds like there may be some differing opinions regarding whether or not it is something we should do. @Lloyd McKenzie -- if we were to do this in SUSHI, it would be an alternate way to indicate what SUSHI generates into the page structure of the IG resource. So from the perspective of the IG Publisher, the IG is still calling the shots. But I suspect your concern is more with the principal of the matter than the technicalities.
Lloyd McKenzie (Mar 30 2021 at 17:33):
I don't want the front matter to be there when the content gets to Jekyll. I'm also not thrilled with a solution that works for markdown but doesn't work for XHTML content authored in SUSHI.
Eric Haas (Mar 30 2021 at 17:35):
@Lloyd McKenzie the templates has taken away a powerful feature of Jekyll and I'm trying to create a simple process to order the pages so the TOC has some resemblance to the menu. I am not a fan of manually editing the ig resource and Sushi is a powerful tool that can be leveraged to make everyone's life easier by tagging the page and letting sushi sort out generating the ig resource . This would work for xhtml too.
Eric Haas (Mar 30 2021 at 17:36):
I don't understand the opposition sushi already is a preprocessor for making the IG resource.
Lloyd McKenzie (Mar 30 2021 at 17:37):
So long as the content gets moved into the IG resource by SUSHI and strips it out of the pages before Jekyll sees them and there's a comparable process that works for XHTML-authored pages, I'm fine with hit.
Eric Haas (Mar 30 2021 at 17:39):
the content is not stripped from the pages this is an example source file:
<!--
---
title: Foo
page-order: '1' #for nesting use dot notation like '1.1'
description: >-
this is my awesome page
---
-->
If the `client_id` is "my-app" and the `client_secret` is "my-app-secret-123",
then the header uses the value B64Encode("my-app:my-app-secret-123"), which
converts to `bXktYXBwOm15LWFwcC1zZWNyZXQtMTIz`. This gives the app the Authorization
token for "Basic Auth".
GET header:
```
Authorization: Basic bXktYXBwOm15LWFwcC1zZWNyZXQtMTIz
```
Eric Haas (Mar 30 2021 at 17:40):
now, having said all that - I would like others to comment on the merits of whether this is a reasonable workaround or not
Lloyd McKenzie (Mar 30 2021 at 17:57):
If it's present and it impacts Jekyll, it's a problem - because the content that drives title, page order, etc. must come from the ImplementationGuide, not the page files. Even if it doesn't impact Jekyll, it's going to be confusing to people.
Eric Haas (Apr 01 2021 at 18:49):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
