2020-10-01 08:33:22 +00:00
|
|
|
import Route from 'consul-ui/routing/route';
|
2019-12-17 18:47:37 +00:00
|
|
|
import { inject as service } from '@ember/service';
|
|
|
|
import { hash } from 'rsvp';
|
ui: Fix using 'ui-like' KVs when using an empty default nspace (#7734)
When using namespaces, the 'default' namespace is a little special in
that we wanted the option for all our URLs to stay the same when using
namespaces if you are using the default namespace, with the option of
also being able to explicitly specify `~default` as a namespace.
In other words both `ui/services/service-name` and
`ui/~default/services/service-name` show the same thing.
This means that if you switch between OSS and Enterprise, all of your
URLs stay the same, but you can still specifically link to the default
namespace itself.
Our routing configuration is duplicated in order to achieve this:
```
- :dc
- :service
- :kv
- :edit
- :nspace
- :dc
- :service
- :kv
- :edit
```
Secondly, ember routing resolves/matches routes in the order that you specify
them, unless, its seems, when using wildcard routes, like we do in the
KV area.
When not using the wildcard routes the above routing configuration
resolves/matches a `/dc-1/kv/service` to the `dc.kv.edit` route correctly
(dc:dc-1, kv:services), that route having been configured in a higher
priority than the nspace routes.
However when configured with wildcards (required in the KV area), note
the asterisk below:
```
- :dc
:service
- :kv
- *edit
- :nspace
- :dc
- :service
- :kv
- *edit
```
Given something like `/dc-1/kv/services` the router instead matches the
`nspace.dc.service` (nspace:dc-1, dc:kv, service:services) route first even
though the `dc.kv.edit` route should still match first.
Changing the `dc.kv.edit` route back to use a non-wildcard route
(:edit instead of *edit), returns the router to match the routes in the
correct order.
In order to work around this, we catch any incorrectly matched routes
(those being directed to the nspace Route but not having a `~`
character in the nspace parameter), and then recalculate the correct
route name and parameters. Lastly we use this recalculated route to
direct the user/app to the correct route.
This route recalcation requires walking up the route to gather up all of
the required route parameters, and although this feels like something
that could already exist in ember, it doesn't seem to. We had already
done a lot of this work a while ago when implementing our `href-mut`
helper. This commit therefore repurposes that work slighlty and externalizes
it outside of the helper itself into a more usable util so we can import
it where we need it. Tests have been added before refactoring it down
to make the code easier to follow.
2020-04-30 08:28:20 +00:00
|
|
|
import { getOwner } from '@ember/application';
|
|
|
|
import { env } from 'consul-ui/env';
|
|
|
|
import transitionable from 'consul-ui/utils/routing/transitionable';
|
2019-12-17 18:47:37 +00:00
|
|
|
|
ui: Fix using 'ui-like' KVs when using an empty default nspace (#7734)
When using namespaces, the 'default' namespace is a little special in
that we wanted the option for all our URLs to stay the same when using
namespaces if you are using the default namespace, with the option of
also being able to explicitly specify `~default` as a namespace.
In other words both `ui/services/service-name` and
`ui/~default/services/service-name` show the same thing.
This means that if you switch between OSS and Enterprise, all of your
URLs stay the same, but you can still specifically link to the default
namespace itself.
Our routing configuration is duplicated in order to achieve this:
```
- :dc
- :service
- :kv
- :edit
- :nspace
- :dc
- :service
- :kv
- :edit
```
Secondly, ember routing resolves/matches routes in the order that you specify
them, unless, its seems, when using wildcard routes, like we do in the
KV area.
When not using the wildcard routes the above routing configuration
resolves/matches a `/dc-1/kv/service` to the `dc.kv.edit` route correctly
(dc:dc-1, kv:services), that route having been configured in a higher
priority than the nspace routes.
However when configured with wildcards (required in the KV area), note
the asterisk below:
```
- :dc
:service
- :kv
- *edit
- :nspace
- :dc
- :service
- :kv
- *edit
```
Given something like `/dc-1/kv/services` the router instead matches the
`nspace.dc.service` (nspace:dc-1, dc:kv, service:services) route first even
though the `dc.kv.edit` route should still match first.
Changing the `dc.kv.edit` route back to use a non-wildcard route
(:edit instead of *edit), returns the router to match the routes in the
correct order.
In order to work around this, we catch any incorrectly matched routes
(those being directed to the nspace Route but not having a `~`
character in the nspace parameter), and then recalculate the correct
route name and parameters. Lastly we use this recalculated route to
direct the user/app to the correct route.
This route recalcation requires walking up the route to gather up all of
the required route parameters, and although this feels like something
that could already exist in ember, it doesn't seem to. We had already
done a lot of this work a while ago when implementing our `href-mut`
helper. This commit therefore repurposes that work slighlty and externalizes
it outside of the helper itself into a more usable util so we can import
it where we need it. Tests have been added before refactoring it down
to make the code easier to follow.
2020-04-30 08:28:20 +00:00
|
|
|
const DEFAULT_NSPACE_PARAM = '~default';
|
2019-12-17 18:47:37 +00:00
|
|
|
export default Route.extend({
|
|
|
|
repo: service('repository/dc'),
|
|
|
|
router: service('router'),
|
ui: Fix using 'ui-like' KVs when using an empty default nspace (#7734)
When using namespaces, the 'default' namespace is a little special in
that we wanted the option for all our URLs to stay the same when using
namespaces if you are using the default namespace, with the option of
also being able to explicitly specify `~default` as a namespace.
In other words both `ui/services/service-name` and
`ui/~default/services/service-name` show the same thing.
This means that if you switch between OSS and Enterprise, all of your
URLs stay the same, but you can still specifically link to the default
namespace itself.
Our routing configuration is duplicated in order to achieve this:
```
- :dc
- :service
- :kv
- :edit
- :nspace
- :dc
- :service
- :kv
- :edit
```
Secondly, ember routing resolves/matches routes in the order that you specify
them, unless, its seems, when using wildcard routes, like we do in the
KV area.
When not using the wildcard routes the above routing configuration
resolves/matches a `/dc-1/kv/service` to the `dc.kv.edit` route correctly
(dc:dc-1, kv:services), that route having been configured in a higher
priority than the nspace routes.
However when configured with wildcards (required in the KV area), note
the asterisk below:
```
- :dc
:service
- :kv
- *edit
- :nspace
- :dc
- :service
- :kv
- *edit
```
Given something like `/dc-1/kv/services` the router instead matches the
`nspace.dc.service` (nspace:dc-1, dc:kv, service:services) route first even
though the `dc.kv.edit` route should still match first.
Changing the `dc.kv.edit` route back to use a non-wildcard route
(:edit instead of *edit), returns the router to match the routes in the
correct order.
In order to work around this, we catch any incorrectly matched routes
(those being directed to the nspace Route but not having a `~`
character in the nspace parameter), and then recalculate the correct
route name and parameters. Lastly we use this recalculated route to
direct the user/app to the correct route.
This route recalcation requires walking up the route to gather up all of
the required route parameters, and although this feels like something
that could already exist in ember, it doesn't seem to. We had already
done a lot of this work a while ago when implementing our `href-mut`
helper. This commit therefore repurposes that work slighlty and externalizes
it outside of the helper itself into a more usable util so we can import
it where we need it. Tests have been added before refactoring it down
to make the code easier to follow.
2020-04-30 08:28:20 +00:00
|
|
|
// The ember router seems to change the priority of individual routes
|
|
|
|
// depending on whether they are wildcard routes or not.
|
|
|
|
// This means that the namespace routes will be recognized before kv ones
|
|
|
|
// even though we define namespace routes after kv routes (kv routes are
|
|
|
|
// wildcard routes)
|
|
|
|
// Therefore here whenever we detect that ember has recognized a nspace route
|
|
|
|
// when it shouldn't (we know this as there is no ~ in the nspace param)
|
|
|
|
// we recalculate the route it should have caught by generating the nspace
|
|
|
|
// equivalent route for the url (/dc-1/kv/services > /~default/dc-1/kv/services)
|
|
|
|
// and getting the information for that route. We then remove the nspace specific
|
|
|
|
// information that we generated onto the route, which leaves us with the route
|
|
|
|
// we actually want. Using this final route information we redirect the user
|
|
|
|
// to where they wanted to go.
|
|
|
|
beforeModel: function(transition) {
|
|
|
|
if (!this.paramsFor('nspace').nspace.startsWith('~')) {
|
|
|
|
const url = `${env('rootURL')}${DEFAULT_NSPACE_PARAM}${transition.intent.url}`;
|
|
|
|
const route = this.router.recognize(url);
|
|
|
|
const [name, ...params] = transitionable(route, {}, getOwner(this));
|
|
|
|
this.replaceWith.apply(this, [
|
|
|
|
// remove the 'nspace.' from the routeName
|
|
|
|
name
|
|
|
|
.split('.')
|
|
|
|
.slice(1)
|
|
|
|
.join('.'),
|
|
|
|
// remove the nspace param from the params
|
|
|
|
...params.slice(1),
|
|
|
|
]);
|
|
|
|
}
|
|
|
|
},
|
2019-12-17 18:47:37 +00:00
|
|
|
model: function(params) {
|
|
|
|
return hash({
|
|
|
|
item: this.repo.getActive(),
|
|
|
|
nspace: params.nspace,
|
|
|
|
});
|
|
|
|
},
|
2020-04-21 15:49:11 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* We need to redirect if someone doesn't specify the section they want,
|
|
|
|
* but not redirect if the 'section' is specified
|
|
|
|
* (i.e. /dc-1/ vs /dc-1/services).
|
|
|
|
*
|
|
|
|
* If the target route of the transition is `nspace.index`, it means that
|
|
|
|
* someone didn't specify a section and thus we forward them on to a
|
|
|
|
* default `.services` subroute. The specific services route we target
|
|
|
|
* depends on whether or not a namespace was specified.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
afterModel(model, transition) {
|
|
|
|
if (transition.to.name === 'nspace.index') {
|
|
|
|
if (model.nspace.startsWith('~')) {
|
|
|
|
this.transitionTo('nspace.dc.services', model.nspace, model.item.Name);
|
2019-12-17 18:47:37 +00:00
|
|
|
} else {
|
2020-04-21 15:49:11 +00:00
|
|
|
this.transitionTo('dc.services', model.nspace);
|
2019-12-17 18:47:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
});
|