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 <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, 2 September 2015 00:32 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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) <rcres...@cisco.com<mailto:rcres...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
