Skip to content

Nested interactive documentation (refs #4965, update of #4966) #5166

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

Closed
wants to merge 11 commits into from

Conversation

drdaeman
Copy link

Hi! I thought I'd take a stab at improving #4966. I've rebased that PR's code upon the current master and made some fixes and changes I've mentioned in comments there.

Differences from #4966:

  1. Commits are rebased upon the current master. Merge conflicts (use of items filter) resolved.
  2. Updated code to handles cases when there are both sub-documents and links at the same level. I've added a test case for this, with @detail_route().
  3. Ensures all HTML IDs only consist of alphanumerics and minus-dashes, so JS won't choke on something unexpected with #some-id lookups (e.g. it had failed on #spam/eggs). I recognize this may be a problem with non-ASCII routes, but I'm not sure how to deal with those. I can think of either using unicode-slugify as an optional dependency, or using hashes instead of human-readable strings. Both options have their downsides, though. Any suggestions?
  4. Adds some tests (a bit dirty, as they parse HTML with regexes and assume a particular structure) that ensure links are consistent and snippet code has correct action lists. If desirable, I can probably add a test-time-only BeautifulSoup dependency, and update tests accordingly, so one would be able to update HTML templates without having to worry about tests. But I feel this is probably an overkill.
  5. I've updated the code to pass paths as lists rather than strings (prefixes), joining them as necessary. I believe this is a a more flexible approach. This still requires a custom template filter (list_add), but it's a more generic one than split_keys.

I've tested this code in a project I work on, and it seems to work nicely, without any issues. Please review this. I'll be glad to hear any suggestions on possible improvements!

Thanks!

nanuxbe and others added 11 commits May 23, 2017 16:06
This essentially continues the changes from 0173e9b.
If the section has both links and sub-documents (nested routes),
then both should be displayed.
We check for Python and JS code (they have the same syntax
for the action list), and shell code snippets, ensuring that
the action is correct for the nested routes.
This way we don't need to do any string manipulation (split_keys is gone),
and snippet code generation should be more flexible.
This is a precaution to avoid JS breaking if some routes would
contain something that doesn't fit well into CSS `#some-id` selectors,
e.g. semicolons or parens.
@smcoll
Copy link

smcoll commented Jul 3, 2017

@drdaeman thanks for writing this up!

One issue i noticed is that the "interact" modal ID can clobber. For example, given two links having these paths:

  • foo > bar > read
  • bar > read

When this line of interact.html is reached, section_key is "bar" in both cases:

<div class="modal fade api-modal" id="{{ section_key }}_{{ link_key }}_modal" tabindex="-1" role="dialog" aria-labelledby="api explorer modal">

The modal ID for both will be bar_read_modal, meaning the wrong modal will appear when the "interact" button is selected in one of those cases.

Seems to me we're going to need some representation of the full path in the modal ID.

@drdaeman
Copy link
Author

drdaeman commented Jul 3, 2017

@smcoll Ooh, thanks for pointing this out - I haven't noticed the lack of path in modal IDs! Just checked the code - yes, it definitely must be there.

I'll revisit and update this PR ASAP when the time would permit (probably, tomorrow)

@carltongibson
Copy link
Collaborator

Thanks for the input here. We've gone with #5334 in the end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy