Closed mojavelinux closed 5 years ago
Want to take a crack at this @rwinch? It could be a good opportunity to give the extension API an exercise. I'd suggest using either a treeprocessor or postprocessor, but if you have another idea, go for it.
Sure it will be fun to play around with the extensions :)
Out of curiosity can you clarify what you mean by when a dedicated label is clicked? In the Syntax Quick Reference guide it is currently adding the link with javascript. Would this be different? Perhaps an example of what the adoc file is expected would be useful.
You have it right. I just meant that the user would click something obvious, like view result to reveal the hidden content.
@mojavelinux I added my first draft of the extension, but I think there are still some shortcomings that probably need addressed before this becomes a PR (mentioned in the commit). Please let me know if you agree or if since this is a lab that it is ok for now.
In addition to the shortcomings listed in the commit comment, I really think it should have some tests. I noticed none of the other extensions in the lab seem to have tests though. I assume you would be ok with me adding some for this extension?
NOTE: Partially why I am asking about the tests is I'm quite the Ruby noob, so I wanted to make sure I wasn't just missing the tests (i.e. in some other repo or something).
Thanks! Rob
Thanks @rwinch!
Since this is a lab, I don't see any problem with merging as is. I agree it would be good to have tests. I haven't had an opportunity yet to sort out what approach we should use for testing...and I'm not well-versed in Ruby-based test frameworks. If you want to give it a shot, perhaps Minitest, RSpec or Cucumber. Here's a pretty straightforward article on Minitest that just came up:
Another possible idea for this extension (or a related one) is to have a result block that is automatically generated. This would only apply for AsciiDoc example content. The extension would copy the contents of a marked listing block and add a new example block with that content as a following sibling. Now that I spell it out, it seems best as a separate extension, perhaps "ViewAsciiDocResultTreeprocessor". It would eliminate the duplication you see in this source: https://raw.githubusercontent.com/asciidoctor/asciidoctor.org/master/docs/asciidoc-syntax-quick-reference.adoc
Given the PR is fine as is and I haven't had time to clean things up. I am going to send the PR. Hopefully in the coming weeks I can find some time to add the remaining polish.
I have added https://github.com/asciidoctor/asciidoctor-extensions-lab/pull/4 along with the suggested changes for a comment about wanting to have an API for modifying the header.
I think we should merge this to encourage participation. I haven't had a chance to play with it, but I've pointed several people in this direction doing similar things. wdyt?
Thanks for the response. Please feel free to merge the PR.
Excellent! Thanks!
Hi all. I see that this extension is merged. Nice!. Is it possible to use it from asciidoctorj? Any advice that points me into the right direction is appreciated. I have asciidoctorj installed by SDKMAN. Thanks.
Create an extension that initially hides example blocks with the role "result" and uses JavaScript to toggle the visibility of the content when a dedicated label (e.g., "View Result") is clicked or touched.
An example of this extension can be seen on the AsciiDoc Syntax Quick Reference page on the Asciidoctor website. Another example can be found in the Groovy documentation.