[openstack-dev] [horizon] URL Sanity
Rob Cresswell (rcresswe)
rcresswe at cisco.com
Tue Sep 1 14:39:03 UTC 2015
Hi all,
I recently started looking into properly implementing breadcrumbs to make navigation clearer, especially around nested resources (Subnets Detail page, for example). The idea is to use the request.path to form a logical breadcrumb that isn’t dependent on browser history ( https://review.openstack.org/#/c/129985/3/horizon/browsers/breadcrumb.py ). Unfortunately, this breaks down quite quickly because we use odd patterns like `<resources>/<resource_id>/detail`, and `<resources>/<resource_id>` doesn’t exist.
This made me realise how much of an inconsistent mess the URL patterns are. I’ve started cleaning them up, so we move from these patterns:
`/admin/networks/<network_id>/detail` - Detail page for a Network
`/admin/networks/<network_id>/addsubnet` - Create page for a Subnet
To patterns in line with usual CRUD usages, such as:
`/admin/networks/<network_id>` - Detail page for a Network
`/admin/networks/<network_id>/subnets/create` - Create page for a Subnet
This is mostly trivial, just removing extraneous words and adding consistency, with end goal being every panel following patterns like:
`/<resources>` - Index page
`/<resources>/<resource_id>` - Detail page for a single resource
`/<resources>/create` - Create new resource
`/<resources>/<resource_id>/update` - Update a resource
This gets a little complex around nested items. Should a Port for example, which has a unique ID, be reachable in Horizon by just its ID? Ports must always be attached to a network as I understand it. There are multiple ways to express this:
`/networks/ports/<port_id>` - Current implementation
`/networks/<network_id>/ports/<port_id>` - My preferred structure
`/ports/<port_id>` - Another option
Does anyone have any opinions on how to handle this structuring, or if it’s even necessary?
Regards,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150901/226b1345/attachment.html>
More information about the OpenStack-dev
mailing list