-
-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Conversation
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.
@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:
When this line of
The modal ID for both will be Seems to me we're going to need some representation of the full path in the modal ID. |
@smcoll Ooh, thanks for pointing this out - I haven't noticed the lack of I'll revisit and update this PR ASAP when the time would permit (probably, tomorrow) |
Thanks for the input here. We've gone with #5334 in the end. |
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:
master
. Merge conflicts (use ofitems
filter) resolved.@detail_route()
.#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?prefix
es), 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 thansplit_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!