-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switching tabs as well as other fragments #107
Conversation
Expanding on the proposal in lightbend#95, added support for having other parts of the documentation change as well when changing a group.
Refs #106 |
The text switching on the spans looks good. Having a general purpose span directive is useful. My first thought for frequently used text groups is whether it would be useful to have it add extra named span directives, rather than just using span classes. Say specifying the possible groups in the build, since these are normally something like Java/Scala and used across the docs, and then having a named span directive like |
I like the idea of configuring 'supergroups' in the build (instead of the directive I added for that) and generating directives for them. Using the group name as directive name should be fine (you'll just have to make sure not to choose group names that clash with other directives) - otherwise This will also help when adding overall switches, too, indeed - and perhaps when implementing #14 we'll actually need it for generating a PDF for each possible selection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -311,7 +311,8 @@ case class SnipDirective(page: Page, variables: Map[String, String]) | |||
} else new File(page.file.getParentFile, source) | |||
val text = Snippet(file, labels) | |||
val lang = Option(node.attributes.value("type")).getOrElse(Snippet.language(file)) | |||
new VerbatimNode(text, lang).accept(visitor) | |||
val group = Option(node.attributes.value("group")).getOrElse("") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about the idea mentioned here: #95 (comment)
That would allow easier adaptation of the group functionality. All of the already written docs could use this feature without any changes to the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely agreed ;)
Removes the need to define the 'supergroup' in the markdown. Next up is of course switching from the dropdown.
First-scala | ||
: @@snip [example-first.scala](../../resources/tab-switching/examples.scala) { #scala_first group=scala } | ||
|
||
Some separator with text describing the @java[Java variant] @scala[Scala variant containing ***markdown*** and @ref:[Linking](linking.md)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I like this a lot - can't wait to use it
When merging, make sure to create a merge commit (as opposed to squash and merge), as this PR contains commits from more than one author. |
: @@snip [example-second.java](../../resources/tab-switching/examples.java) | ||
|
||
Scala | ||
: @@snip [example-second.scala](../../resources/tab-switching/examples.scala) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The example markdown does not match the markdown for render.
Its a pity I was not able to try it out, as paradox itself does not use the same code to generate the docs. |
For snippets, the group now defaults to the type of snippet (e.g. java/scala).
I tried this out on the Cinnamon docs. The Cinnamon docs also uses tabs that shouldn't be switched. We have example Given that we now have a declarative list of the switchable groups in the build, I'm wondering if we could use that as a whitelist for switching (by injecting it into the template for the javascript part). And instead of looking for classes on code blocks in tabs, could we simply use the tab name itself (and match against the known groups). So for the Cinnamon docs, we would define the switchable tabs as |
@pvlugter yes that makes a lot of sense to me! |
What's the status on this PR? Is it ready to be merged? |
@eed3si9n I think it might make sense to implement the ideas by @pvlugter before merging, and perhaps add hooks to customize the behavior on tab change (as e.g. for the akka docs we might want to do a page refresh instead of client-side switching until we've migrated all pages to support that). @pvlugter WDYT? |
ok. Sounds good. |
SGTM |
@raboof are you going to work on these changes? |
Yes if that doesn't interfere with your work I think I can look into it today! |
Great, sounds good. |
Though definition lists that don't contain any code snippets currently don't become tabs, this makes things a bit more robust.
I've made some changes, including:
I think this makes this PR ready for merge, review welcome. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! LGTM!
Also tried it out on the Cinnamon docs and works great there.
Expanding on the proposal in #95, added support for having other parts of
the documentation change as well when switching groups.