Skip to content
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

Add support for sub-indexes #31

Closed
HelloGrayson opened this issue Dec 7, 2017 · 0 comments · Fixed by #120
Closed

Add support for sub-indexes #31

HelloGrayson opened this issue Dec 7, 2017 · 0 comments · Fixed by #120

Comments

@HelloGrayson
Copy link
Contributor

Packages that have subpackages, like net/ in net/metrics currently 404.

Instead, we should render the same index that is shown at /, but scoped to that package.

For example, given the packages:

  • go.uber.org/net/metrics
  • go.uber.org/net/auth

Navigating to https://go.uber.org/net would show an index containing the above 2 packages.

abhinav added a commit to abhinav/sally that referenced this issue Oct 15, 2023
<details>
<summary>Background</summary>

Sally renders two kinds of pages:

- packages: These are for packages defined in sally.yaml
  and any route under the package path.
- indexes: These list available packages.

The latter--indexes was previously only supported at '/', the root page.

This leads to a slight UX issue:
if you have a package with a / in its name (e.g. net/metrics):

- example.com/net/metrics gives you the package page
- example.com/ lists net/metrics
- However, example.com/net fails with a 404

</details>

This adds support for index pages on all parents of package pages.
Therefore, if example.com/net/metrics exists,
example.com/net will list all packages defined under that path.

To make this possible, the internals have been rewritten to some degree:
CreateHandler no longer builds an http.ServeMux
with a bunch of pre-registered http.Handlers.
It now builds a custom http.Handler with its own routing.

Routing is backed by a new pathTree abstraction.
pathTree is a specialized string-value storage
with support for inheriting values from a parent.
It has the following methods:

- `Set(path, v)` associates v with path.
- `Lookup(path)` returns the value at path,
  or the value inherited from the closest ancestor.
- `ListByPath(path)` lists all values at or under the given path.

For additional confidence in the implementation of pathTree,
a property test based on rapid is included.

Resolves uber-go#31
abhinav added a commit to abhinav/sally that referenced this issue Oct 15, 2023
<details>
<summary>Background</summary>

Sally renders two kinds of pages:

- packages: These are for packages defined in sally.yaml
  and any route under the package path.
- indexes: These list available packages.

The latter--indexes was previously only supported at '/', the root page.

This leads to a slight UX issue:
if you have a package with a / in its name (e.g. net/metrics):

- example.com/net/metrics gives you the package page
- example.com/ lists net/metrics
- However, example.com/net fails with a 404

</details>

This adds support for index pages on all parents of package pages.
Therefore, if example.com/net/metrics exists,
example.com/net will list all packages defined under that path.

To make this possible, the internals have been rewritten to some degree:
CreateHandler no longer builds an http.ServeMux
with a bunch of pre-registered http.Handlers.
It now builds a custom http.Handler with its own routing.

Routing is backed by a new pathTree abstraction.
pathTree is a specialized string-value storage
with support for inheriting values from a parent.
It has the following methods:

- `Set(path, v)` associates v with path.
- `Lookup(path)` returns the value at path,
  or the value inherited from the closest ancestor.
- `ListByPath(path)` lists all values at or under the given path.

For additional confidence in the implementation of pathTree,
a property test based on rapid is included.

Resolves uber-go#31
abhinav added a commit that referenced this issue Oct 18, 2023
<details>
<summary>Background</summary>

Sally renders two kinds of pages:

- packages: These are for packages defined in sally.yaml
  and any route under the package path.
- indexes: These list available packages.

The latter--indexes was previously only supported at '/', the root page.

This leads to a slight UX issue:
if you have a package with a / in its name (e.g. net/metrics):

- example.com/net/metrics gives you the package page
- example.com/ lists net/metrics
- However, example.com/net fails with a 404

</details>

This adds support for index pages on all parents of package pages.
Therefore, if example.com/net/metrics exists,
example.com/net will list all packages defined under that path.

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

Successfully merging a pull request may close this issue.

1 participant