[openstack-dev] [horizon] URL Sanity
Rob Cresswell (rcresswe)
rcresswe at cisco.com
Wed Sep 2 09:30:15 UTC 2015
Yeah, the “legacy” thought is what’s making me second guess the effort. We’re still in limbo with the language focus, IMO.
Are we nearing a change in routing? I remember work being demo’d at the last summit, but I haven’t seen any of it since.
From: Richard Jones <r1chardj0n3s at gmail.com<mailto:r1chardj0n3s at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, 2 September 2015 00:32
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] URL Sanity
Interesting idea, and in general I'm for consistency. I can't speak directly to the network/port question, though it seems to me that if ports must be attached to networks then it makes sense for the URL to reflect that.
On the other hand, some could argue that the django URL routing is ... legacy ... and shouldn't me messed with :)
On the gripping hand, thinking about this could inform future angular routing planning...
On 2 September 2015 at 00:39, Rob Cresswell (rcresswe) <rcresswe at cisco.com<mailto:rcresswe at cisco.com>> wrote:
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/b803cc40/attachment.html>
More information about the OpenStack-dev
mailing list